Merlin Moncure <mmonc...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
