> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
