Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit3b35f9a

Browse files
author
Richard Guo
committed
Fix an incorrect check in get_memoize_path
Memoize typically marks cache entries as complete after fully scanningthe inner side of a join. However, in the case of unique joins, weskip to the next outer tuple as soon as the first matching inner tupleis found, leaving no opportunity to scan the inner side to completion.To work around that, we mark cache entries as complete after fetchingthe first matching inner tuple in unique joins.This approach is only safe when all of the join's restriction clausesare parameterized; otherwise, there is no guarantee that reading justone tuple from the inner side is sufficient.Currently, we check for this by verifying that the number of clausesin ppi_clauses is no less than the number of the join's restrictionclauses. However, this check isn't entirely reliable, as ppi_clausesincludes join clauses available from all outer rels, not just thecurrent outer rel. This means the check could pass even if arestriction clause isn't parameterized, as long as another joinclause, which doesn't belong to the current join, is included inppi_clauses.To fix this, we explicitly check whether each restriction clause ofthe current join is present in ppi_clauses.While we're here, remove the XXX comment from the modified code, asit's not justified; in certain cases, it's not possible to move a joinclause to the inner side.This is arguably a bugfix, but no backpatch given the lack of fieldreports.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/CAMbWs4-8JPouj=wBDj4DhK-WO4+Xdx=A2jbjvvyyTBQneJ1=BQ@mail.gmail.com
1 parent5ee4762 commit3b35f9a

File tree

1 file changed

+15
-9
lines changed

1 file changed

+15
-9
lines changed

‎src/backend/optimizer/path/joinpath.c

Lines changed: 15 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -748,16 +748,22 @@ get_memoize_path(PlannerInfo *root, RelOptInfo *innerrel,
748748
*
749749
* Lateral vars needn't be considered here as they're not considered when
750750
* determining if the join is unique.
751-
*
752-
* XXX this could be enabled if the remaining join quals were made part of
753-
* the inner scan's filter instead of the join filter. Maybe it's worth
754-
* considering doing that?
755751
*/
756-
if (extra->inner_unique&&
757-
(inner_path->param_info==NULL||
758-
bms_num_members(inner_path->param_info->ppi_serials)<
759-
list_length(extra->restrictlist)))
760-
returnNULL;
752+
if (extra->inner_unique)
753+
{
754+
Bitmapset*ppi_serials;
755+
756+
if (inner_path->param_info==NULL)
757+
returnNULL;
758+
759+
ppi_serials=inner_path->param_info->ppi_serials;
760+
761+
foreach_node(RestrictInfo,rinfo,extra->restrictlist)
762+
{
763+
if (!bms_is_member(rinfo->rinfo_serial,ppi_serials))
764+
returnNULL;
765+
}
766+
}
761767

762768
/*
763769
* We can't use a memoize node if there are volatile functions in the

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp