From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: BRIN index and aborted transaction |
Date: | 2015-07-24 01:14:04 |
Message-ID: | 20150724011404.GB5596@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2015-07-24 03:15:14 | Re: pgbench - allow backslash-continuations in custom scripts |
Previous Message | Kouhei Kaigai | 2015-07-24 00:27:33 | Re: fdw_scan_tlist for foreign table scans breaks EPQ testing, doesn't it? |