Re: Execution time from >1s -> 80m+ when extra columns added in SELECT for sub-query

2020-05-18 Thread Tom Lane
A Guy Named Ryan writes: > Why would the planner switch plans so drastically given that all I'm > doing is including a few extra columns in the subselect, particularly > when those columns are discarded by the super? parent? subselect The problem is that the columns you're adding *don't belong to

Re: Execution time from >1s -> 80m+ when extra columns added in SELECT for sub-query

2020-05-18 Thread A Guy Named Ryan
Thanks for responding! On May 18, 2020 at 12:18:37 PM, Pavel Stehule ([email protected](mailto:[email protected])) wrote: > Hi > > It looks so in slow plan is some strange relations between subselects - the > slow plan looks like plan for correlated subquery, and it should be slow.

Re: Execution time from >1s -> 80m+ when extra columns added in SELECT for sub-query

2020-05-18 Thread Pavel Stehule
Hi It looks so in slow plan is some strange relations between subselects - the slow plan looks like plan for correlated subquery, and it should be slow. Minimally you miss a index on column jtemp1c37l3b_baseline_windows_after_inclusion.uuid