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 getting propagated
> from wor
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 CONFLICT (see "other_path" in
> >
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 Instrumentation; that'd be
a
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 being set as all-visible". Th
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 of the test could prevent pages
>> from being
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 looked at this closely, b
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 think we should do that.
>
>
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
> simple, it seems reason
Robert Haas wrote:
>
> I don't have a strong opinion on that. Since we know how many tuples
> were processed by each worker, knowing how many heap fetches we have
> on a per-worker basis seems like a good thing to have, too. On the
> other hand, maybe EXPLAIN (ANALYZE, VERBOSE) would give us tha
