Re: [sqlsmith] Failed to generate plan on lateral subqueries
| От | Tom Lane |
|---|---|
| Тема | Re: [sqlsmith] Failed to generate plan on lateral subqueries |
| Дата | |
| Msg-id | 2650.1449705974@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [sqlsmith] Failed to generate plan on lateral subqueries (Merlin Moncure <mmoncure@gmail.com>) |
| Ответы |
Re: [sqlsmith] Failed to generate plan on lateral subqueries
|
| Список | pgsql-hackers |
Merlin Moncure <mmoncure@gmail.com> writes:
> Aside from the functional issues, could your changes result in
> performance regressions? (if so, I'd argue not to backpatch unless
> there were cases that returned bad data as opposed to spurious
> errors).
I can't say that I think planner failures on valid queries is something
that's optional to fix. However, I believe that this will typically
not change the selected plan in cases where the planner didn't fail
before. I did notice one change in an existing regression test, where
the planner pushed a qual clause further down in the plan than it did
before; but that seems like a better plan anyway. (The reason that
happened is that the changes to enlarge the minimum parameterization
of some base rels result in choosing to push qualifiers further down,
since a qual clause will be evaluated at the lowest plan level that
the selected parameterization allows.)
It's a little bit harder to gauge the impact on planner speed. The
transitive closure calculation could be expensive in a query with many
lateral references, but that doesn't seem likely to be common; and anyway
we'll buy back some of that cost due to simpler tests later. I'm
optimistic that we'll come out ahead in HEAD/9.5 after the removal
of LateralJoinInfo setup. It might be roughly a wash in the back
branches.
regards, tom lane
В списке pgsql-hackers по дате отправления: