Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mXo6G-0007wb-2o for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Oct 2021 17:19:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mXo6D-00011E-Oy for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Oct 2021 17:19:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mXo6D-000116-Gj for pgsql-hackers@lists.postgresql.org; Tue, 05 Oct 2021 17:19:29 +0000 Received: from mail-qt1-x834.google.com ([2607:f8b0:4864:20::834]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mXo6B-0004dk-F7 for pgsql-hackers@lists.postgresql.org; Tue, 05 Oct 2021 17:19:28 +0000 Received: by mail-qt1-x834.google.com with SMTP id l13so19856424qtv.3 for ; Tue, 05 Oct 2021 10:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=systemguards-com-ec.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=QjsdBc9boxT0jhcK0XmQ+qE1SGn5DTk6PHUE4kuR8Ng=; b=JBsFD6/Mkm46sQr9Y7G3xp041O3lAnRBc82FQKNJwF41bE/aG9pnKx1vToD6YyGdbm nlixRh5/U7wfm9IY9reYCjWIZ3YP1SYMdJB0Vm7OhGD7iai9uVxuPyBZrUm4OlFRXQZP m1o1kyHzeZ+V5sdZihuFx5zb78mKmXw42ioto6BYHs1ISgvTY4KYl/EpwpBWWASoRv3a Yjl/RGgPV4OG0y7b0y2Tce1CfqjeOQB3cERIrKqkKLxm8IazgeowTRDSW7M49puMyZtI QV+y9s/9zq+ljgutASXi3uIUY8okh4ztw6Fd02detOj2Ia3yWdjhsSAxlsJcgqEQjX3l rGYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=QjsdBc9boxT0jhcK0XmQ+qE1SGn5DTk6PHUE4kuR8Ng=; b=YReQ1FukyqaS0d0r+RAiWBRu8aV2XmobOir4LaF3inhXmZmxMGHI05mKIH8jpscfJh ij0xg20lHouw295y4mPZiPpfIiY/KhHtlHsFBL9gZefqNOUxvuk7JGZtxbqV1brCOqHI kS4wECGmOSZ+2K/pyji/lWeqmY5Alv/vMdzXNyWvwymDyiVa+2hbs7ZK+QsVb2HzAzTZ L9R8xzsGdCKPCEf6KkRgqgNQnUAGIc41T/paGDlOBddpp9eQ1/vJZvgwXX5jK4SIUcCM BWFn+WjyAswrtc4WENZRTEpprL54gYIsQQ+ybOh1OdTMU161Ot1hPf6P5hvmdg/AxCQ6 82ug== X-Gm-Message-State: AOAM530I1XISJO0aQ8urcJcQukchyrv9OM6E5DwzLVe8WFnku+NVqMPE +iFrBdQOldas3gT+yVzTuUouuA== X-Google-Smtp-Source: ABdhPJzgtg597a2EYA6PJeV/FgbL+b5x8fE3VncE1sIASOXhgbvpXHM4o0qtwcKjHw6m4J7DCkNWIg== X-Received: by 2002:ac8:5a86:: with SMTP id c6mr21442316qtc.3.1633454366426; Tue, 05 Oct 2021 10:19:26 -0700 (PDT) Received: from ahch-to ([201.183.0.184]) by smtp.gmail.com with ESMTPSA id u20sm9968782qke.66.2021.10.05.10.19.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 10:19:25 -0700 (PDT) Date: Tue, 5 Oct 2021 12:19:22 -0500 From: Jaime Casanova To: Richard Guo Cc: Ashutosh Bapat , Anastasia Lubennikova , Pg Hackers , Richard Guo , ashutosh.bapat@enterprisedb.com Subject: Re: A problem about partitionwise join Message-ID: <20211005171922.GB28628@ahch-to> References: <160467632488.7362.12712548134124442813.pgcf@coridan.postgresql.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jul 21, 2021 at 04:44:53PM +0800, Richard Guo wrote: > On Fri, Nov 27, 2020 at 8:05 PM Ashutosh Bapat > wrote: > > > > > In the example you gave earlier, the equi join on partition key was > > there but it was replaced by individual constant assignment clauses. > > So if we keep the original restrictclause in there with a new flag > > indicating that it's redundant, have_partkey_equi_join will still be > > able to use it without much change. Depending upon where all we need > > to use avoid restrictclauses with the redundant flag, this might be an > > easier approach. However, with Tom's idea partition-wise join may be > > used even when there is no equi-join between partition keys but there > > are clauses like pk = const for all tables involved and const is the > > same for all such tables. > > > > Correct. So with Tom's idea partition-wise join can cope with clauses > such as 'foo.k1 = bar.k1 and foo.k2 = 16 and bar.k2 = 16'. > > > > > > In the spirit of small improvement made to the performance of > > have_partkey_equi_join(), pk_has_clause should be renamed as > > pk_known_equal and pks_known_equal as num_equal_pks. > > > > Thanks for the suggestion. Will do that in the new version of patch. > Hi Richard, We are marking this CF entry as "Returned with Feedback", which means you are encouraged to send a new patch (and create a new entry for a future CF for it) with the suggested changes. -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de PostgreSQL