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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers