BRIN indexes (was Re: Minmax indexes)

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: BRIN indexes (was Re: Minmax indexes)
Date: 2014-09-08 16:02:20
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Here's version 18. I have renamed it: These are now BRIN indexes.

I have fixed numerous race conditions and deadlocks. In particular I
fixed this problem you noted:

Heikki Linnakangas wrote:
> Another race condition:
> If a new tuple is inserted to the range while summarization runs,
> it's possible that the new tuple isn't included in the tuple that
> the summarization calculated, nor does the insertion itself udpate
> it.

I did it mostly in the way you outlined, i.e. by way of a placeholder
tuple that gets updated by concurrent inserters and then the tuple
resulting from the scan is unioned with the values in the updated
placeholder tuple. This required the introduction of one extra support
proc for opclasses (pretty simple stuff anyhow).

There should be only minor items left now, such as silencing the

WARNING: concurrent insert in progress within table "sales"

which is emitted by IndexBuildHeapScan (possibly thousands of times)
when doing a summarization of a range being inserted into or otherwise
modified. Basically the issue here is that IBHS assumes it's being run
with ShareLock in the heap (which blocks inserts), but here we're using
it with ShareUpdateExclusive only, which lets inserts in. There is no
harm AFAICS because of the placeholder tuple stuff I describe above.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
minmax-18.patch text/x-diff 192.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2014-09-08 16:28:12 Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index
Previous Message Heikki Linnakangas 2014-09-08 15:47:00 Re: gist vacuum gist access