pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Correctly identify which EC members are computable at a plan nod 6+ messages / 1 participants [nested] [flat]
* pgsql: Correctly identify which EC members are computable at a plan nod @ 2024-10-12 18:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-10-12 18:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Correctly identify which EC members are computable at a plan node. find_computable_ec_member() had the wrong mental model of what its primary caller prepare_sort_from_pathkeys() would do with the selected EquivalenceClass member expression. We will not compute the EC expression in a plan node atop the one returning the passed-in targetlist; rather, the EC expression will be computed as an additional column of that targetlist. So any Var or quasi-Var used in the given tlist is also available to the EC expression. In simple cases this makes no difference because the given tlist is just a list of Vars or quasi-Vars --- but if we are considering an appendrel member produced by flattening a UNION ALL, the tlist may contain expressions, resulting in failure to match and a "could not find pathkey item to sort" error. To fix, we can flatten both the tlist and the EC members with pull_var_clause(), and then just check for subset-ness, so that the code is actually shorter than before. While this bug is quite old, the present patch only works back to v13. We could possibly make it work in v12 by back-patching parts of 375398244. On the whole though I don't like the risk/reward ratio of that idea. v12's final release is next month, meaning there would be no chance to correct matters if the patch causes a regression. Since this failure has escaped notice for 14 years, it's likely nobody will hit it in the field with v12. Per bug #18652 from Alexander Lakhin. Andrei Lepikhov and Tom Lane Discussion: https://postgr.es/m/18652-deaa782ebcca85d1@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/9f954177b1eb0f890a8e1f4ebaf90bea54c4871b Modified Files -------------- src/backend/optimizer/path/equivclass.c | 71 +++++++++++++++------------------ src/test/regress/expected/inherit.out | 30 ++++++++++++++ src/test/regress/sql/inherit.sql | 8 ++++ 3 files changed, 71 insertions(+), 38 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Correctly identify which EC members are computable at a plan nod @ 2024-10-12 18:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-10-12 18:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Correctly identify which EC members are computable at a plan node. find_computable_ec_member() had the wrong mental model of what its primary caller prepare_sort_from_pathkeys() would do with the selected EquivalenceClass member expression. We will not compute the EC expression in a plan node atop the one returning the passed-in targetlist; rather, the EC expression will be computed as an additional column of that targetlist. So any Var or quasi-Var used in the given tlist is also available to the EC expression. In simple cases this makes no difference because the given tlist is just a list of Vars or quasi-Vars --- but if we are considering an appendrel member produced by flattening a UNION ALL, the tlist may contain expressions, resulting in failure to match and a "could not find pathkey item to sort" error. To fix, we can flatten both the tlist and the EC members with pull_var_clause(), and then just check for subset-ness, so that the code is actually shorter than before. While this bug is quite old, the present patch only works back to v13. We could possibly make it work in v12 by back-patching parts of 375398244. On the whole though I don't like the risk/reward ratio of that idea. v12's final release is next month, meaning there would be no chance to correct matters if the patch causes a regression. Since this failure has escaped notice for 14 years, it's likely nobody will hit it in the field with v12. Per bug #18652 from Alexander Lakhin. Andrei Lepikhov and Tom Lane Discussion: https://postgr.es/m/18652-deaa782ebcca85d1@postgresql.org Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/54889ea64baaa5970330a0097fb6689ee1af7591 Modified Files -------------- src/backend/optimizer/path/equivclass.c | 71 +++++++++++++++------------------ src/test/regress/expected/inherit.out | 30 ++++++++++++++ src/test/regress/sql/inherit.sql | 8 ++++ 3 files changed, 71 insertions(+), 38 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Correctly identify which EC members are computable at a plan nod @ 2024-10-12 18:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-10-12 18:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Correctly identify which EC members are computable at a plan node. find_computable_ec_member() had the wrong mental model of what its primary caller prepare_sort_from_pathkeys() would do with the selected EquivalenceClass member expression. We will not compute the EC expression in a plan node atop the one returning the passed-in targetlist; rather, the EC expression will be computed as an additional column of that targetlist. So any Var or quasi-Var used in the given tlist is also available to the EC expression. In simple cases this makes no difference because the given tlist is just a list of Vars or quasi-Vars --- but if we are considering an appendrel member produced by flattening a UNION ALL, the tlist may contain expressions, resulting in failure to match and a "could not find pathkey item to sort" error. To fix, we can flatten both the tlist and the EC members with pull_var_clause(), and then just check for subset-ness, so that the code is actually shorter than before. While this bug is quite old, the present patch only works back to v13. We could possibly make it work in v12 by back-patching parts of 375398244. On the whole though I don't like the risk/reward ratio of that idea. v12's final release is next month, meaning there would be no chance to correct matters if the patch causes a regression. Since this failure has escaped notice for 14 years, it's likely nobody will hit it in the field with v12. Per bug #18652 from Alexander Lakhin. Andrei Lepikhov and Tom Lane Discussion: https://postgr.es/m/18652-deaa782ebcca85d1@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/64635c8af92dafa94a807331c2f0f0b3d6aff402 Modified Files -------------- src/backend/optimizer/path/equivclass.c | 71 +++++++++++++++------------------ src/test/regress/expected/inherit.out | 30 ++++++++++++++ src/test/regress/sql/inherit.sql | 8 ++++ 3 files changed, 71 insertions(+), 38 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Correctly identify which EC members are computable at a plan nod @ 2024-10-12 18:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-10-12 18:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Correctly identify which EC members are computable at a plan node. find_computable_ec_member() had the wrong mental model of what its primary caller prepare_sort_from_pathkeys() would do with the selected EquivalenceClass member expression. We will not compute the EC expression in a plan node atop the one returning the passed-in targetlist; rather, the EC expression will be computed as an additional column of that targetlist. So any Var or quasi-Var used in the given tlist is also available to the EC expression. In simple cases this makes no difference because the given tlist is just a list of Vars or quasi-Vars --- but if we are considering an appendrel member produced by flattening a UNION ALL, the tlist may contain expressions, resulting in failure to match and a "could not find pathkey item to sort" error. To fix, we can flatten both the tlist and the EC members with pull_var_clause(), and then just check for subset-ness, so that the code is actually shorter than before. While this bug is quite old, the present patch only works back to v13. We could possibly make it work in v12 by back-patching parts of 375398244. On the whole though I don't like the risk/reward ratio of that idea. v12's final release is next month, meaning there would be no chance to correct matters if the patch causes a regression. Since this failure has escaped notice for 14 years, it's likely nobody will hit it in the field with v12. Per bug #18652 from Alexander Lakhin. Andrei Lepikhov and Tom Lane Discussion: https://postgr.es/m/18652-deaa782ebcca85d1@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4f3bccbaaeb44d2568a387ce02e4c3d95237628c Modified Files -------------- src/backend/optimizer/path/equivclass.c | 71 +++++++++++++++------------------ src/test/regress/expected/inherit.out | 30 ++++++++++++++ src/test/regress/sql/inherit.sql | 8 ++++ 3 files changed, 71 insertions(+), 38 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Correctly identify which EC members are computable at a plan nod @ 2024-10-12 18:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-10-12 18:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Correctly identify which EC members are computable at a plan node. find_computable_ec_member() had the wrong mental model of what its primary caller prepare_sort_from_pathkeys() would do with the selected EquivalenceClass member expression. We will not compute the EC expression in a plan node atop the one returning the passed-in targetlist; rather, the EC expression will be computed as an additional column of that targetlist. So any Var or quasi-Var used in the given tlist is also available to the EC expression. In simple cases this makes no difference because the given tlist is just a list of Vars or quasi-Vars --- but if we are considering an appendrel member produced by flattening a UNION ALL, the tlist may contain expressions, resulting in failure to match and a "could not find pathkey item to sort" error. To fix, we can flatten both the tlist and the EC members with pull_var_clause(), and then just check for subset-ness, so that the code is actually shorter than before. While this bug is quite old, the present patch only works back to v13. We could possibly make it work in v12 by back-patching parts of 375398244. On the whole though I don't like the risk/reward ratio of that idea. v12's final release is next month, meaning there would be no chance to correct matters if the patch causes a regression. Since this failure has escaped notice for 14 years, it's likely nobody will hit it in the field with v12. Per bug #18652 from Alexander Lakhin. Andrei Lepikhov and Tom Lane Discussion: https://postgr.es/m/18652-deaa782ebcca85d1@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4ca708eb3588d36a714f0e40f6cc49f63dfe25cb Modified Files -------------- src/backend/optimizer/path/equivclass.c | 71 +++++++++++++++------------------ src/test/regress/expected/inherit.out | 30 ++++++++++++++ src/test/regress/sql/inherit.sql | 8 ++++ 3 files changed, 71 insertions(+), 38 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Correctly identify which EC members are computable at a plan nod @ 2024-10-12 18:56 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2024-10-12 18:56 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Correctly identify which EC members are computable at a plan node. find_computable_ec_member() had the wrong mental model of what its primary caller prepare_sort_from_pathkeys() would do with the selected EquivalenceClass member expression. We will not compute the EC expression in a plan node atop the one returning the passed-in targetlist; rather, the EC expression will be computed as an additional column of that targetlist. So any Var or quasi-Var used in the given tlist is also available to the EC expression. In simple cases this makes no difference because the given tlist is just a list of Vars or quasi-Vars --- but if we are considering an appendrel member produced by flattening a UNION ALL, the tlist may contain expressions, resulting in failure to match and a "could not find pathkey item to sort" error. To fix, we can flatten both the tlist and the EC members with pull_var_clause(), and then just check for subset-ness, so that the code is actually shorter than before. While this bug is quite old, the present patch only works back to v13. We could possibly make it work in v12 by back-patching parts of 375398244. On the whole though I don't like the risk/reward ratio of that idea. v12's final release is next month, meaning there would be no chance to correct matters if the patch causes a regression. Since this failure has escaped notice for 14 years, it's likely nobody will hit it in the field with v12. Per bug #18652 from Alexander Lakhin. Andrei Lepikhov and Tom Lane Discussion: https://postgr.es/m/18652-deaa782ebcca85d1@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/76de4b182cad1e53e01a52c78cf24f4e13b36253 Modified Files -------------- src/backend/optimizer/path/equivclass.c | 71 +++++++++++++++------------------ src/test/regress/expected/inherit.out | 30 ++++++++++++++ src/test/regress/sql/inherit.sql | 8 ++++ 3 files changed, 71 insertions(+), 38 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-10-12 18:56 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-10-12 18:56 pgsql: Correctly identify which EC members are computable at a plan nod Tom Lane <tgl@sss.pgh.pa.us> 2024-10-12 18:56 pgsql: Correctly identify which EC members are computable at a plan nod Tom Lane <tgl@sss.pgh.pa.us> 2024-10-12 18:56 pgsql: Correctly identify which EC members are computable at a plan nod Tom Lane <tgl@sss.pgh.pa.us> 2024-10-12 18:56 pgsql: Correctly identify which EC members are computable at a plan nod Tom Lane <tgl@sss.pgh.pa.us> 2024-10-12 18:56 pgsql: Correctly identify which EC members are computable at a plan nod Tom Lane <tgl@sss.pgh.pa.us> 2024-10-12 18:56 pgsql: Correctly identify which EC members are computable at a plan nod Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox