Re: BRIN indexes (was Re: Minmax indexes)

From: Emanuel Calvo <3manuek(at)esdebian(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: BRIN indexes (was Re: Minmax indexes)
Date: 2014-09-15 01:08:31
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

El 08/09/14 13:02, Alvaro Herrera escribió:
> 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.

Debuging VACUUM VERBOSE ANALYZE over a concurrent table being

Breakpoint 1, errfinish (dummy=0) at elog.c:411
411 ErrorData *edata = &errordata[errordata_stack_depth];

The complete backtrace is at

Also, I found pages with an unkown type (using deafult parameters for
the index

brin_page_type | array_agg
unknown (00) | {3,4}
revmap | {1}
regular | {2}
meta | {0}
(4 rows)


Emanuel Calvo

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-15 01:20:54 Re: pgbench throttling latency limit
Previous Message Arthur Silva 2014-09-14 23:42:36 Re: [REVIEW] Re: Compression of full-page-writes