Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
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
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.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
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
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
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?
regards, tom lane
--
Sent via
Alvaro Herrera alvhe...@2ndquadrant.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
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
