David Rowley writes:
> You're right that OFFSET 0 would have been a better choice. I just
> wasn't aware that we were considering changing the code so we pull up
> subqueries with an ORDER BY.
No such plan is in the offing AFAIK, but it doesn't seem entirely
out of the question either.
> In
On Tue, 24 Jan 2023 at 12:37, Tom Lane wrote:
> Hmmm ... we have an agreed syntax for a subquery optimization fence,
> and that ain't it. I wouldn't count on this not breaking again in
> the future. Why not OFFSET 0, which is the usual method?
You're right that OFFSET 0 would have been a
David Rowley writes:
> Here we add a simple ORDER BY to stop the planner from being able to
> pullup the lateral subquery.
Hmmm ... we have an agreed syntax for a subquery optimization fence,
and that ain't it. I wouldn't count on this not breaking again in
the future. Why not OFFSET 0, which
Fix LATERAL join test in test memoize.sql
The test in question was meant to be testing Memoize to ensure it worked
correctly when the inner side of the join contained lateral vars, however,
nothing in the lateral subquery stopped it from being pulled up into the
main query, so the planner did
Fix LATERAL join test in test memoize.sql
The test in question was meant to be testing Memoize to ensure it worked
correctly when the inner side of the join contained lateral vars, however,
nothing in the lateral subquery stopped it from being pulled up into the
main query, so the planner did
Fix LATERAL join test in test memoize.sql
The test in question was meant to be testing Memoize to ensure it worked
correctly when the inner side of the join contained lateral vars, however,
nothing in the lateral subquery stopped it from being pulled up into the
main query, so the planner did
