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

From Thomas Munro
Subject Re: [HACKERS] brin autosummarization -- autovacuum "work items"
Date
Msg-id CAEepm=0FSzkxdCMMX8xR6NcAH6QZL8xkbyjTo6YAVHDPcLdHgQ@mail.gmail.com
Whole thread Raw
In response to [HACKERS] brin autosummarization -- autovacuum "work items"  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] brin autosummarization -- autovacuum "work items"  (Thomas Munro <thomas.munro@enterprisedb.com>)
Re: [HACKERS] brin autosummarization -- autovacuum "work items"  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Wed, Mar 1, 2017 at 5:58 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> I think one of the most serious issues with BRIN indexes is how they
> don't get updated automatically as the table is filled.  This patch
> attempts to improve on that.  During brininsert() time, we check whether
> we're inserting the first item on the first page in a range.  If we are,
> request autovacuum to do a summarization run on that table.  This is
> dependent on a new reloption for BRIN called "autosummarize", default
> off.

Nice.

> The way the request works is that autovacuum maintains a DSA which can
> be filled by backends with "work items".  Currently, work items can
> specify a BRIN summarization of some specific index; in the future we
> could use this framework to request other kinds of things that do not
> fit in the "dead tuples / recently inserted tuples" logic that autovac
> currently uses to decide to vacuum/analyze tables.
>
> However, it seems I have not quite gotten the hang of DSA just yet,
> because after a couple of iterations, crashes occur.  I think the reason
> has to do with either a resource owner clearing the DSA at an unwelcome
> time, or perhaps there's a mistake in my handling of DSA "relative
> pointers" stuff.

Ok, I'll take a look.  It's set up for ease of use in short lifespan
situations like parallel query, and there are a few extra hoops to
jump through for longer lived DSA areas.

-- 
Thomas Munro
http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: Re: [HACKERS] [POC] hash partitioning
Next
From: Kuntal Ghosh
Date:
Subject: Re: [HACKERS] Performance degradation in TPC-H Q18