On 2023-Jan-19, Amit Langote wrote: > It seems that, with the test as written, it's not the partitioned > table referenced in the view's query that becomes a child of the UNION > ALL parent subquery, but the subquery itself. The bug being fixed in > 0002 doesn't affect the planning of this query at all, because child > subquery is planned independently of the main query involving UNION > ALL because of it being unable to be pushed up into the latter. We > want the partitioned table referenced in the child subquery to become > a child of the UNION ALL parent subquery for the bug to be relevant. > > I tried rewriting the test such that the view's subquery does get > pulled up such that the partitioned table becomes a child of the UNION > ALL subquery. By attaching a debugger, I do see the bug affecting the > planning of this query, but still not in a way that changes the plan. > I will keep trying but in the meantime I'm attaching 0001 to show the > rewritten query and the plan.
Thanks for spending time tracking down a test case. I'll try to have a look later today. > > As for 0001, it seems simpler to me to put the 'userid' variable in the > > same scope as 'onerel', and then compute it just once and don't bother > > with it at all afterwards, as in the attached. > > That sounds better. Attached as 0002. Pushed this one, thank you. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
