Re: BRIN index and aborted transaction

Tatsuo Ishii wrote:
> > Hm, well, I am not sure that we want to pay the overhead of
> > re-summarization every time we prune a single tuple from a block range.
> > That's going to make vacuum much slower, I assume (without measuring);
> > many page ranges are going to be re-summarized without this actually
> > changing the range.
> 
> What I'm interested in is, if there's a case that using BRIN index is
> slower than plain sequential scan (or planner is stupid enough to
> choose BRIN index scan over sequential scan even if the former is
> slower).

No, that shouldn't be an issue.  If brin degrades completely, the worst
that can happen is a seqscan.  There is very small overhead, but the
index itself is small and should be very quick to scan.

> If such that case exists, we may want to fix it before releasing 9.5.

I'm going to try to get the issue addressed in 9.5 along the lines we
discussed upthread.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services