From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: What is HeapScanDescData.rs_initblock good for? |
Date: | 2015-07-23 15:53:41 |
Message-ID: | 20150723155341.GS5596@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > Tom Lane wrote:
> >> The BRIN patch added a HeapScanDescData field rs_initblock, but so far as
> >> I can see it's utterly without use, and it's quite confusing (people might
> >> mistake it for rs_startblock, for example). Any objection to taking it
> >> out again?
>
> > Ouch, you're right, my mistake. Feel free to remove it, yeah.
>
> ... While I'm looking at it, it sure looks like the BRIN patch broke
> syncscan for those index build methods that were using it, which was
> most. You've got IndexBuildHeapRangeScan unconditionally calling
> heap_setscanlimits and thereby trashing the result of ss_get_location().
Hmm, right, I failed to notice that.
> I'm inclined to let it call heap_setscanlimits only if not allow_sync.
It is possible for a partial range scan to join an existing herd of
scans that happens to be processing that part of the table, in which
case this wouldn't be sufficient. However, two considerations: 1) range
scans, at least for BRIN, aren't normally large enough for synscans to
matter all that much; and 2) it would require additional code. So I'm
inclined to do it as you suggest, which is simplest.
(I think this is what the rs_initblock thing was for BTW: set up an
initial block number other than 0 for the range scan, so that when it
reached the end in a syncscan that started further ahead, it knew what
block to "overflow" back to.)
One scenario in which the sync scan could matter is initial index
creation.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Brightwell | 2015-07-23 16:08:18 | Re: security labels on databases are bad for dump & restore |
Previous Message | Robert Haas | 2015-07-23 15:52:02 | Re: proposal: multiple psql option -c |