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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to