> 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

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

Best regards,
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php

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

Reply via email to