Thomas Munro wrote: > What is your motivation for using DSA? It seems you are creating an > area and then using it to make exactly one allocation of a constant > size known up front to hold your fixed size workitems array. You > don't do any dynamic allocation at runtime, apart from the detail that > it happens to allocated on demand. Perhaps it would make sense if you > had a separate space per database or something like that, so that the > shared memory need would be dynamic?
Well, the number of work items is currently fixed; but if you have many BRIN indexes, then you'd overflow (lose requests). By using DSA I am making it easy to patch this afterwards so that an arbitrary number of requests can be recorded. > It looks like outstanding autosummarisation work will be forgotten if > you restart before it is processed. That's true. However, it would be easy to make index scans also request work items if they find a full page range that should have been summarized, so if they are lost, it's not a big deal. > Over in another thread[1] we > exchanged emails on another way to recognise that summarisation work > needs to be done, if we are only interested in unsummarised ranges at > the end of the heap. I haven't studied BRIN enough to know if that is > insufficient: can you finish up with unsummarised ranges not in a > contiguous range at the end of the heap? If we include my other patch to remove the index tuple for a certain range, then yes, it can happen. (That proposed patch requires manual action, but range invalidation could also be invoked automatically when, say, a certain number of tuples are removed from a page range.) > If so, perhaps the BRIN > index itself should also have a way to record that certain non-final > ranges are unsummarised but should be summarised asynchronously? I think this is unnecessary, and would lead to higher operating overhead. With this patch, it's very cheap to file a work item. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers