aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistvalidate.c
diff options
context:
space:
mode:
authorRichard Guo <rguo@postgresql.org>2025-07-03 10:57:26 +0900
committerRichard Guo <rguo@postgresql.org>2025-07-03 10:57:26 +0900
commit0da29e4cb161f78a5ef534b3fb4467756a422e25 (patch)
tree35c08e6b5d93c05c496d940bfc9593d9e4756576 /src/backend/access/gist/gistvalidate.c
parent7b2eb72b1b8ce4279e42848a3978e781ae239355 (diff)
downloadpostgresql-0da29e4cb161f78a5ef534b3fb4467756a422e25.tar.gz
postgresql-0da29e4cb161f78a5ef534b3fb4467756a422e25.zip
Enable use of Memoize for ANTI joins
Currently, we do not support Memoize for SEMI and ANTI joins because nested loop SEMI/ANTI joins do not scan the inner relation to completion, which prevents Memoize from marking the cache entry as complete. One might argue that we could mark the cache entry as complete after fetching the first inner tuple, but that would not be safe: if the first inner tuple and the current outer tuple do not satisfy the join clauses, a second inner tuple matching the parameters would find the cache entry already marked as complete. However, if the inner side is provably unique, this issue doesn't arise, since there would be no second matching tuple. That said, this doesn't help in the case of SEMI joins, because a SEMI join with a provably unique inner side would already have been reduced to an inner join by reduce_unique_semijoins. Therefore, in this patch, we check whether the inner relation is provably unique for ANTI joins and enable the use of Memoize in such cases. Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com> Reviewed-by: Andrei Lepikhov <lepihov@gmail.com> Discussion: https://postgr.es/m/CAMbWs48FdLiMNrmJL-g6mDvoQVt0yNyJAqMkv4e2Pk-5GKCZLA@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist/gistvalidate.c')
0 files changed, 0 insertions, 0 deletions