Re: BRIN index and aborted transaction

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  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?