aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/skipsupport.c
diff options
context:
space:
mode:
authorAlexander Korotkov <akorotkov@postgresql.org>2025-04-04 16:01:50 +0300
committerAlexander Korotkov <akorotkov@postgresql.org>2025-04-04 16:01:50 +0300
commitc0962a113d1f2f94cb7222a7ca025a67e9ce3860 (patch)
tree6da1bad29d2394bca13b4c29c4df5ae9a4ceee67 /src/backend/utils/adt/skipsupport.c
parentd48d2e2dc8be50d3ca13305b5699384329b15433 (diff)
downloadpostgresql-c0962a113d1f2f94cb7222a7ca025a67e9ce3860.tar.gz
postgresql-c0962a113d1f2f94cb7222a7ca025a67e9ce3860.zip
Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate
This commit implements the automatic conversion of 'x IN (VALUES ...)' into ScalarArrayOpExpr. That simplifies the query tree, eliminating the appearance of an unnecessary join. Since VALUES describes a relational table, and the value of such a list is a table row, the optimizer will likely face an underestimation problem due to the inability to estimate cardinality through MCV statistics. The cardinality evaluation mechanism can work with the array inclusion check operation. If the array is small enough (< 100 elements), it will perform a statistical evaluation element by element. We perform the transformation in the convert_ANY_sublink_to_join() if VALUES RTE is proper and the transformation is convertible. The conversion is only possible for operations on scalar values, not rows. Also, we currently support the transformation only when it ends up with a constant array. Otherwise, the evaluation of non-hashed SAOP might be slower than the corresponding Hash Join with VALUES. Discussion: https://postgr.es/m/0184212d-1248-4f1f-a42d-f5cb1c1976d2%40tantorlabs.com Author: Alena Rybakina <a.rybakina@postgrespro.ru> Author: Andrei Lepikhov <lepihov@gmail.com> Reviewed-by: Ivan Kush <ivan.kush@tantorlabs.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Diffstat (limited to 'src/backend/utils/adt/skipsupport.c')
0 files changed, 0 insertions, 0 deletions