Re: [HACKERS] brin autosummarization -- autovacuum "work items" - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] brin autosummarization -- autovacuum "work items"
Date
Msg-id 20170321201016.ptnikbwwxpbr6eo6@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] brin autosummarization -- autovacuum "work items"  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: brin autosummarization -- autovacuum "work items"  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: brin autosummarization -- autovacuum "work items"  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Next
From: Vitaly Burovoy
Date:
Subject: Re: [HACKERS] identity columns