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 1rztP9-007hj2-Ch for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2024 07:20:27 +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 1rztP8-0042wR-0Q for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2024 07:20:26 +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 1rztP7-0042vn-Mn for pgsql-hackers@lists.postgresql.org; Thu, 25 Apr 2024 07:20:25 +0000 Received: from mail-yb1-xb30.google.com ([2607:f8b0:4864:20::b30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rztP5-004Y0t-A0 for pgsql-hackers@postgresql.org; Thu, 25 Apr 2024 07:20:24 +0000 Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-de54b28c41eso796643276.0 for ; Thu, 25 Apr 2024 00:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714029622; x=1714634422; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=sNTAc69G+5xoO8tQEvVQF1cnDFPRvvSBFKl+VCxbCwg=; b=NIUM2T5DrqwrCMPh/ZJ+IqJKYG9iqrzDOl2rq4kpz0BdtcGytxVfvNsgUlC4c4sviP CTvDWFpsTK/WgZSX9eKMXN9GcsQM+4MRkk+JNt2v54h8YEVJWVIm9qK0ttuPFXVOiozg mDcL0kRpo/2meOKyeuikVxT2fD4JY4lbl7nzlZnnCujdYHyUr/g3rMSlLlWODOHaSXyb 1CCxhpYC46x/refMWPjombtLu7m4DmKOLHO1uuyuzHeFu+B6mjjgjXEyLuIDFc92PEZp DsQP70aVe8nKMK0UQXQa7VdlnSn06FWx6HW2ODV9YZke9WVLxwwCoKorlTgi7NZ28yiQ TrhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714029622; x=1714634422; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sNTAc69G+5xoO8tQEvVQF1cnDFPRvvSBFKl+VCxbCwg=; b=Uu44JF0h049a0oIgAbeqT/zxgnlV5Pgf23wsdtMC8pehxeqwehu8jP7SO03q6FGsIR 1ElxwO1zuagmcOUBIt/N4k2N/DUHABbu14Y1feZPdT70nM9HX3g2A5b1pFLr++kEUQVb e8NVMzmtGBQZJIZDUntxQyQIiTUvDZnDwwh2L2BkVt2g/wDVi0tXdBhcSjtxwxtUstbe vanFcjFNTLpfIbyFNvpPTKWGmWBlKWHJLJlCUWHzTpRO3e7bFAUAhZ5nDAetw5zwOkZh 1+as9+Y3/gruRuttyUIUqPTdnThkGaPVnp8ll39wHdIRJWuMXH/vfNGkaa38ZtWpF72O No4w== X-Gm-Message-State: AOJu0YzDpbrvfT7ImTRdx5OJfzKHL9cfO4wr/J9Ne1wPZcspKi2qJYAQ c4ZNZOb5Go4fhGuwWcMbX6GDBqJTxslnT8CgcC8DxtZhVO6Gi0pTyyCsHx21YXpaAYJcFtK+B0B XK7LJWzSNRhsexoDZ3WV3dVx1tP+1dWZC X-Google-Smtp-Source: AGHT+IE9HXS/ESH6OvhWOc3UpRr1qZltX4MW7atE1bRj8E72MKy523zhpr4OGWuftOxT/hhbLA5TnIARlyMtZ7iksAw= X-Received: by 2002:a25:b126:0:b0:de1:2206:a87e with SMTP id g38-20020a25b126000000b00de12206a87emr5126849ybj.13.1714029621808; Thu, 25 Apr 2024 00:20:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Guo Date: Thu, 25 Apr 2024 15:20:10 +0800 Message-ID: Subject: Re: Short-circuit sort_inner_and_outer if there are no mergejoin clauses To: PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000be16e70616e69e3e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000be16e70616e69e3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 24, 2024 at 5:13=E2=80=AFPM Richard Guo wrote: > 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. > FWIW, during the run of the core regression tests, I found that we enter sort_inner_and_outer with an empty mergeclause_list a total of 11064 times. Out of these occurrences, there are 293 instances where the join type is JOIN_UNIQUE_OUTER, indicating the need to create a UniquePath for the outer path. Similarly, there are also 293 instances where the join type is JOIN_UNIQUE_INNER, indicating the need to create a UniquePath for the inner path. Thanks Richard --000000000000be16e70616e69e3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Apr 24, 2024 at 5:13=E2=80=AFPM R= ichard Guo <guofenglinux@gmail= .com> wrote:
In sort_inner_and_outer, we create mergejoin join path= s by explicitly
sorting both relations on each possible ordering of the = available
mergejoin clauses.=C2=A0 However, if there are no available me= rgejoin
clauses, we can skip this process entirely.=C2=A0 It seems that = this is a
relatively common scenario.=C2=A0 Checking the regression test= s I noticed
that there are a lot of cases where we would arrive here wit= h an empty
mergeclause_list.

FWIW,= during the run of the core regression tests, I found that we enter
sort= _inner_and_outer with an empty mergeclause_list a total of 11064
times.= =C2=A0 Out of these occurrences, there are 293 instances where the join
= type is JOIN_UNIQUE_OUTER, indicating the need to create a UniquePath
fo= r the outer path.=C2=A0 Similarly, there are also 293 instances where thejoin type is JOIN_UNIQUE_INNER, indicating the need to create a
Unique= Path for the inner path.

Thanks
Richard
--000000000000be16e70616e69e3e--