Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rzYh0-004rmu-H5 for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Apr 2024 09:13:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rzYgy-00DIWt-SA for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Apr 2024 09:13:28 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rzYgy-00DIMn-CI for pgsql-hackers@lists.postgresql.org; Wed, 24 Apr 2024 09:13:28 +0000 Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rzYgv-004OD7-Kd for pgsql-hackers@postgresql.org; Wed, 24 Apr 2024 09:13:27 +0000 Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-dc23bf7e5aaso6973368276.0 for ; Wed, 24 Apr 2024 02:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713950004; x=1714554804; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=RZs9SPF8uYhEKk470caem4KtmlSSIvTPEjunULdUWug=; b=On+ZwRV1V+L6lz8FZSWjAqoOD3TPRC4/jYwtS4UQuOEzz1cXUOtoi6R+yxABdJXLcn HwRFSQ9DxzecrPjiZoDpwSXjTzICe1HlKeYmk2J66g+NO9Jl+letbhdCHgyufjcKfcVw iOW+w+4B1/dh7aMG1QXzl19ls4xEBsWFw/HPZRL+CyK9ZGRuD9M1FsgmfKSJh7NhmLD7 m3HPZqwq8blih9EqWFpmVHw8O+F3leS0rYkFc2ChMlE3WEkc0gfgFTGByRxR8+QfGJTf E8IJqzRLmrHRzIV4ZuyP6xUEOf6BW9wRB2PF/w6VHTZ//lkWgVLUSoouaGbmxjs/WhuL nbgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713950004; x=1714554804; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=RZs9SPF8uYhEKk470caem4KtmlSSIvTPEjunULdUWug=; b=r1qobx+8BzLSF6O5DPP1J863ydgzFk5VvHfr8MbG5kOgU+n9EvPsKqTayj4ZhUFQx/ ymGOntFqGmQ/CNDwagtFdA/3hvJ6yWHljSJVUjYZFoMkDH9k7euFbRBolxnbYYuSyQN+ YsET5uJTRROVW8Yg8+/DwyyleAEhrSeH1jhjAnmqtApCGwNtI1v0r22x/uoYqa+biBKw GLwF0XSU++6LUNMBldtzt89cXkhsakaRzYe0nmJq/frBSL2Aw6r/gzeX4wHrHcXSMWSj ei9aK5nndEINQFlcC2s1FWAf9ave0CYU1CQLuFJFjtFJN8xKHkl+aBKFlgefJ+QmYQCD nHqw== X-Gm-Message-State: AOJu0YytFp1IlNufwsDprhdBUHqdfkniIGES5eOcedU6vavi7HC4uNKS ZclGufGa1qRgrlmcuo48ayUb8EinWZhn7rOZ9AR9wKsXQggl+Ul48W4GPzVcnS6TysfySmouRP8 AX3Ts03yQxapDsqowWK0WH5h1IQCTy+pX X-Google-Smtp-Source: AGHT+IH63+RSTTosDySDvqAL6fxveWW8S9CfRAvlMV3eW59/CliMnaJruS5C/xcw7cZJPEtTbxGIwd6s74RrkuoKeXY= X-Received: by 2002:a25:848f:0:b0:dcc:1dc4:15e4 with SMTP id v15-20020a25848f000000b00dcc1dc415e4mr1703588ybk.47.1713950004033; Wed, 24 Apr 2024 02:13:24 -0700 (PDT) MIME-Version: 1.0 From: Richard Guo Date: Wed, 24 Apr 2024 17:13:12 +0800 Message-ID: Subject: Short-circuit sort_inner_and_outer if there are no mergejoin clauses To: PostgreSQL-development Content-Type: multipart/mixed; boundary="0000000000002755a80616d415f3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002755a80616d415f3 Content-Type: multipart/alternative; boundary="0000000000002755a60616d415f1" --0000000000002755a60616d415f1 Content-Type: text/plain; charset="UTF-8" In sort_inner_and_outer, we create mergejoin join paths by explicitly sorting both relations on each possible ordering of the available mergejoin clauses. However, if there are no available mergejoin clauses, we can skip this process entirely. It seems that this is a relatively common scenario. Checking the regression tests I noticed that there are a lot of cases where we would arrive here with an empty mergeclause_list. So I'm wondering if it's worth considering a shortcut in sort_inner_and_outer by checking if mergeclause_list is empty. This can help skip all the statements preceding select_outer_pathkeys_for_merge. In particular this may help avoid building UniquePath paths in the case of JOIN_UNIQUE_OUTER or JOIN_UNIQUE_INNER. I asked this because in the "Right Semi Join" patch [1] I wanted to exclude mergejoin from being considered for JOIN_RIGHT_SEMI. So I set mergeclause_list to NIL, but noticed that it still runs the statements in sort_inner_and_outer until no available outer pathkeys are found in select_outer_pathkeys_for_merge. Attached is a trivial patch for this. Thoughts? [1] https://www.postgresql.org/message-id/flat/CAMbWs4_X1mN%3Dic%2BSxcyymUqFx9bB8pqSLTGJ-F%3DMHy4PW3eRXw%40mail.gmail.com Thanks Richard --0000000000002755a60616d415f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In sort_inner_and_outer, we create mergejoin join paths by= explicitly
sorting both relations on each possible ordering of the avai= lable
mergejoin clauses.=C2=A0 However, if there are no available mergej= oin
clauses, we can skip this process entirely.=C2=A0 It seems that this= is a
relatively common scenario.=C2=A0 Checking the regression tests I = noticed
that there are a lot of cases where we would arrive here with an= empty
mergeclause_list.

So I'm wondering if it's worth c= onsidering a shortcut in
sort_inner_and_outer by checking if mergeclause= _list is empty.=C2=A0 This can
help skip all the statements preceding se= lect_outer_pathkeys_for_merge.
In particular this may help avoid buildin= g UniquePath paths in the case
of JOIN_UNIQUE_OUTER or JOIN_UNIQUE_INNER= .

I asked this because in the "Right Semi Join" patch [1] = I wanted to
exclude mergejoin from being considered for JOIN_RIGHT_SEMI.= =C2=A0 So I set
mergeclause_list to NIL, but noticed that it still runs = the statements
in sort_inner_and_outer until no available outer pathkeys= are found in
select_outer_pathkeys_for_merge.

Attached is a triv= ial patch for this.=C2=A0 Thoughts?

--0000000000002755a60616d415f1-- --0000000000002755a80616d415f3 Content-Type: application/octet-stream; name="v1-0001-Short-circuit-sort_inner_and_outer-if-there-are-no-mergejoin-clauses.patch" Content-Disposition: attachment; filename="v1-0001-Short-circuit-sort_inner_and_outer-if-there-are-no-mergejoin-clauses.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lvdljg0f0 RnJvbSBjMGIwMTdmNjQ5NGE2MGM3ZjUxMDJkNWFmOTQyODE4OGI3YTYxZmZjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSaWNoYXJkIEd1byA8Z3VvZmVuZ2xpbnV4QGdtYWlsLmNvbT4K RGF0ZTogV2VkLCAyNCBBcHIgMjAyNCAwOTowNDo0OCArMDAwMApTdWJqZWN0OiBbUEFUQ0ggdjFd IFNob3J0LWNpcmN1aXQgc29ydF9pbm5lcl9hbmRfb3V0ZXIgaWYgdGhlcmUgYXJlIG5vCiBtZXJn ZWpvaW4gY2xhdXNlcwoKSW4gc29ydF9pbm5lcl9hbmRfb3V0ZXIsIHdlIGNyZWF0ZSBtZXJnZWpv aW4gam9pbiBwYXRocyBieSBleHBsaWNpdGx5CnNvcnRpbmcgYm90aCByZWxhdGlvbnMgb24gZWFj aCBwb3NzaWJsZSBvcmRlcmluZyBvZiB0aGUgYXZhaWxhYmxlCm1lcmdlam9pbiBjbGF1c2VzLiAg SG93ZXZlciwgaWYgdGhlcmUgYXJlIG5vIGF2YWlsYWJsZSBtZXJnZWpvaW4KY2xhdXNlcywgd2Ug Y2FuIHNraXAgdGhpcyBwcm9jZXNzIGVudGlyZWx5LgoKVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIGEg Y2hlY2sgZm9yIG1lcmdlY2xhdXNlX2xpc3QgYXQgdGhlIGJlZ2lubmluZyBvZgpzb3J0X2lubmVy X2FuZF9vdXRlciBhbmQgZXhpdHMgdGhlIGZ1bmN0aW9uIGlmIGl0IGlzIGZvdW5kIHRvIGJlIGVt cHR5LgpUaGlzIG1pZ2h0IGhlbHAgc2tpcCBhbGwgdGhlIHN0YXRlbWVudHMgdGhhdCBjb21lIGJl Zm9yZSB0aGUgY2FsbCB0bwpzZWxlY3Rfb3V0ZXJfcGF0aGtleXNfZm9yX21lcmdlLCBpbmNsdWRp bmcgdGhlIGJ1aWxkIG9mIFVuaXF1ZVBhdGggcGF0aHMKaW4gdGhlIGNhc2Ugb2YgSk9JTl9VTklR VUVfT1VURVIgb3IgSk9JTl9VTklRVUVfSU5ORVIuCi0tLQogc3JjL2JhY2tlbmQvb3B0aW1pemVy L3BhdGgvam9pbnBhdGguYyB8IDQgKysrKwogMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygr KQoKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL29wdGltaXplci9wYXRoL2pvaW5wYXRoLmMgYi9z cmMvYmFja2VuZC9vcHRpbWl6ZXIvcGF0aC9qb2lucGF0aC5jCmluZGV4IDViZThkYTllMDkuLmRi YmMxOGU1NmMgMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL29wdGltaXplci9wYXRoL2pvaW5wYXRo LmMKKysrIGIvc3JjL2JhY2tlbmQvb3B0aW1pemVyL3BhdGgvam9pbnBhdGguYwpAQCAtMTI3OCw2 ICsxMjc4LDEwIEBAIHNvcnRfaW5uZXJfYW5kX291dGVyKFBsYW5uZXJJbmZvICpyb290LAogCUxp c3QJICAgKmFsbF9wYXRoa2V5czsKIAlMaXN0Q2VsbCAgICpsOwogCisJLyogTm90aGluZyB0byBk byBpZiB0aGVyZSBhcmUgbm8gYXZhaWxhYmxlIG1lcmdlam9pbiBjbGF1c2VzICovCisJaWYgKGV4 dHJhLT5tZXJnZWNsYXVzZV9saXN0ID09IE5JTCkKKwkJcmV0dXJuOworCiAJLyoKIAkgKiBXZSBv bmx5IGNvbnNpZGVyIHRoZSBjaGVhcGVzdC10b3RhbC1jb3N0IGlucHV0IHBhdGhzLCBzaW5jZSB3 ZSBhcmUKIAkgKiBhc3N1bWluZyBoZXJlIHRoYXQgYSBzb3J0IGlzIHJlcXVpcmVkLiAgV2Ugd2ls bCBjb25zaWRlcgotLSAKMi4zNC4xCgo= --0000000000002755a80616d415f3--