Re: [HACKERS] why not parallel seq scan for slow functions
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] why not parallel seq scan for slow functions |
Дата | |
Msg-id | 364.1504725507@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] why not parallel seq scan for slow functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] why not parallel seq scan for slow functions
|
Список | 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 по дате отправления: