Re: BRIN index and aborted transaction

> 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).

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
Japanese:http://www.sraoss.co.jp