Re: [HACKERS] why not parallel seq scan for slow functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] why not parallel seq scan for slow functions
Date
Msg-id 364.1504725507@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] why not parallel seq scan for slow functions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] why not parallel seq scan for slow functions
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If somebody's applying apply_projection_to_path to a path that's already
>> been add_path'd, that's a violation of the documented restriction.

> /me is confused.  Isn't that exactly what grouping_planner() is doing,
> and has done ever since your original pathification commit
> (3fc6e2d7f5b652b417fa6937c34de2438d60fa9f)?  It's iterating over
> current_rel->pathlist, so surely everything in there has been
> add_path()'d.

I think the assumption there is that we no longer care about validity of
the input Relation, since we won't be looking at it any more (and
certainly not adding more paths to it).  If there's some reason why
that's not true, then maybe grouping_planner has a bug there.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Fix performance of generic atomics
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Fix performance of generic atomics