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 1m8ZIM-00046z-64 for pgsql-performance@arkaria.postgresql.org; Wed, 28 Jul 2021 02:27:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m8ZIK-0008QV-En for pgsql-performance@arkaria.postgresql.org; Wed, 28 Jul 2021 02:27:40 +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 1m8ZIK-0008QN-1D for pgsql-performance@lists.postgresql.org; Wed, 28 Jul 2021 02:27:40 +0000 Received: from mail-il1-x136.google.com ([2607:f8b0:4864:20::136]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m8ZIH-0001Ug-CR for pgsql-performance@lists.postgresql.org; Wed, 28 Jul 2021 02:27:38 +0000 Received: by mail-il1-x136.google.com with SMTP id a14so1288400ila.1 for ; Tue, 27 Jul 2021 19:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=TmMiT7EuWCMf84f5Kk27g5Ycw+PoWG4Z25E1f7c1Gw8=; b=T7bGKYlGnnwDBRjURlb0UFkA9gyjAgHD55G1u75+gLcmjP4EFC/AJvmJ4oUiEe4yjy yDVvMaMqQt08751LaThKL4I4TxDUkWzOXB7WZ1eJYv2hTokhyGG6MCs5im3ga0B0rm++ JVrATIG6AZ8szH8j/2u6eHVdoLYXizy38Sk6d2Bps4EF9PJJfSruk8A6CLkwE3ryn6dV lTOopzQ9eqqO56cTzuzLSvbl7QksXYPmHZXFBMsBuUAyAcMuAKeKH6sKpLj9ZPJkFQsp bnrq0HPMx03vkAZE0WbtCht2f4Rb+2uHUNq9kiuUYBbV1z0vYSO9jQPP3GeFJOMCaI7d VNTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=TmMiT7EuWCMf84f5Kk27g5Ycw+PoWG4Z25E1f7c1Gw8=; b=nJB1qalodfCoj+Ie3MBA2EjZKeofu+edSgBfPRWhTIBGAPqzNcO7S8wwGJMBBNw7OT pqcWS+HzAw+cme7JN2a03Qmcv867A2xUX2pdPn7IeLUUkNBDABVDYtJXD16OWQXFFnlw AgpslBBpyv5pXT5HsnV3HNSdtjwboNLO+vrfirqQC2+FXMSJieDvCZMuLai71dgV75Hi UpnARU4pKCV/gIgfNWPaBFXIZyugkYVZY9JuSUjfkaxxcC2QcEp2loC2GFdgEWSegEPK yJXpkqhiBQ0vpoPxz6FuNSFHIKbXu6vvKOdjVewfjSq54IwVErketZaeRRJYJN8rWakx w06A== X-Gm-Message-State: AOAM5310z1+u8NntidNGLXdB8zKFUeAFDL8cf/QSjWaelsj6WzyngNGp 8WLzAOwUr8Oub9xku1Sf3OBmCGG3gCpf7Q== X-Google-Smtp-Source: ABdhPJxg8WnqwKi3mG+OJoYPDKmomkK+6JCxkpX4V2RoVNlwW6jza3Tn0fDPClhkXfAaPGuWrRX54A== X-Received: by 2002:a05:6e02:dc4:: with SMTP id l4mr19503685ilj.94.1627439255725; Tue, 27 Jul 2021 19:27:35 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id y7sm513110ilh.51.2021.07.27.19.27.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jul 2021 19:27:35 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id F105B800AE5; Tue, 27 Jul 2021 21:27:33 -0500 (CDT) Date: Tue, 27 Jul 2021 21:27:33 -0500 From: Justin Pryzby To: Simen Andreas Andreassen =?iso-8859-1?Q?L=F8nsethagen?= Cc: pgsql-performance@lists.postgresql.org Subject: Re: Performance of lateral join Message-ID: <20210728022733.GM23997@telsasoft.com> References: <20210726181745.GE23997@telsasoft.com> <58EEA217-E918-49C0-987A-E634AD6BB1B2@fremtind.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <58EEA217-E918-49C0-987A-E634AD6BB1B2@fremtind.no> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jul 27, 2021 at 09:08:49AM +0000, Simen Andreas Andreassen Lønsethagen wrote: > > Easy first question: is the temp table analyzed before being used in a join ? > > No, I haven't done that. Today, I tried to run > > ANALYZE records_to_filter_on; > > on the same sample data set (3.75 million rows) before the join, and it did not seem to make much of a difference in terms of time (new output of EXPLAIN ANALYZE at https://explain.dalibo.com/plan/YZu - it seems very similar to me). If the "shape" of the plan didn't change, then ANALYZE had no effect. I think you'd see an improvement if both tables were ordered by foedselsnummer. It might be that that's already somewhat/partially true (?) I suggest to create an index on the temp table's r.foedselsnummer, CLUSTER on that index, and then ANALYZE the table. The index won't be useful for this query, it's just for clustering (unless you can instead populate the temp table in order). Check if there's already high correlation of dpd_bis_foedselsnummer (over 0.9): | SELECT tablename, attname, inherited, null_frac, n_distinct, correlation FROM pg_stats WHERE attname='dpd_bis_foedselsnummer' AND tablename='...'; If not, consider clustering on the existing "unique_descending" index and then analyzing that table, too. This would also affect performance of other queries - hopefully improving several things at once. -- Justin