Re: pgsql: Support partition pruning at execution time

On Tue, Apr 10, 2018 at 12:29 PM, Alvaro Herrera wrote: > In contrast, in an indexonly scan you have a single counter and it > doesn't really matter the distribution of fetches done by workers, so it > seems okay to aggregate them all in a single counter. And it being so

Re: pgsql: Support partition pruning at execution time

Robert Haas wrote: > On Tue, Apr 10, 2018 at 11:14 AM, Alvaro Herrera > wrote: > > Questions: > > 1. Do we want to back-patch this to 10? I suppose (without checking) > > that EXPLAIN ANALYZE is already reporting bogus numbers for parallel > > index-only scans, so I

Re: pgsql: Support partition pruning at execution time

On Tue, Apr 10, 2018 at 11:14 AM, Alvaro Herrera wrote: > Questions: > 1. Do we want to back-patch this to 10? I suppose (without checking) > that EXPLAIN ANALYZE is already reporting bogus numbers for parallel > index-only scans, so I think we should do that. I haven't

Re: pgsql: Support partition pruning at execution time

On 11 April 2018 at 03:42, Tom Lane wrote: > Alvaro Herrera writes: >> 2. Do we want to revert Andrew's test stabilization patch? If I >> understand correctly, the problem is the inverse of what was diagnosed: >> "any running transaction at the time

Re: pgsql: Support partition pruning at execution time

On 11 April 2018 at 03:14, Alvaro Herrera wrote: > 2. Do we want to revert Andrew's test stabilization patch? If I > understand correctly, the problem is the inverse of what was diagnosed: > "any running transaction at the time of the test could prevent pages > from

Re: pgsql: Support partition pruning at execution time

Alvaro Herrera writes: > Questions: > 1. Do we want to back-patch this to 10? I suppose (without checking) > that EXPLAIN ANALYZE is already reporting bogus numbers for parallel > index-only scans, so I think we should do that. You can't back-patch a change in struct

Re: pgsql: Support partition pruning at execution time

Changed CC to pgsql-hackers. Tom Lane wrote: > Alvaro Herrera writes: > > Frankly, I don't like this. I would rather have an instrument->ntuples2 > > rather than these "divide this by nloops, sometimes" schizoid counters. > > This is already being misused by ON

Re: pgsql: Support partition pruning at execution time

Tom Lane wrote: > Alvaro Herrera writes: > > Support partition pruning at execution time > > Buildfarm member lapwing doesn't like this. I can reproduce the > failures here by setting force_parallel_mode = regress. Kind > of looks like instrumentation counts aren't