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 1jT6So-0006di-Fy for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Apr 2020 16:18:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jT6Sn-0002hH-CK for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Apr 2020 16:18:33 +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 1jT6Sn-0002hA-10 for pgsql-hackers@lists.postgresql.org; Mon, 27 Apr 2020 16:18:33 +0000 Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jT6Sj-0002nB-2S for pgsql-hackers@lists.postgresql.org; Mon, 27 Apr 2020 16:18:31 +0000 Received: by mail-qk1-x741.google.com with SMTP id l78so18568585qke.7 for ; Mon, 27 Apr 2020 09:18:28 -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:in-reply-to:user-agent; bh=0jEKguo5Y21Ldn6mVG+11iKmVx5BxpY4WTlnwiYbjnU=; b=SNbWq0QSAx++MB9cPnOXBKm2aGi6WpaaZov9AOMw7kzDY1q0ls1tEoYTQm4tTdMJK/ PFeW9gv23C/YNzLa2trbjBTmqZxaGuxf/1IM+sSyj/1pd5I3lhpF/5zCeBUeBLw1tbri pszKWBp59pBfquoeJKiBSEF5xX+r1I3fnvnqUgP0oCKhy6M05S50Q1wcEz6CE5yvf0WA JzUK4jcxnL/mBC7xPn05WdAVk+dbVBfxoSSagKnlsC5nJhzY2zPcfWPFpmguUNQCyJcD j2q8ZEa3bu64MbR3zrqgto6Ap6JZ6efDKp9E9O9F7fJg/WSUFgJhC/KHcJRRKIL/Qzds 605w== 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:in-reply-to:user-agent; bh=0jEKguo5Y21Ldn6mVG+11iKmVx5BxpY4WTlnwiYbjnU=; b=G30ALv9zfSt/OAqB63K+ttJB+bRSOjVen6rx6kU1ggRIHf9kbM5n3qftGF2uqCgAux OSrZlhMGHv+zwxAXT9u9JcHiBYvQXCP6EdtZRY1ajT1X2bVmXJqsC8erBr6a5Jxh6Ug9 A0VC8LVbrva53koLBS9uj9fdx8ksjhwt3S1ob39dM8r31KzYEQ9lFb6OQ1+LVS85Dmwh i4JKBYy2//GJx37xHbPc7mGVsZhPILnfSRScZv/YuFhGSkq3Ye51J1R8748IWX2U+UNr YFCLFIJVqWp0oXDeofwgW8971cerKgMkFfFMBNoPD1mMBQU2ZP4/HjqqavwAyGIgKser GTdQ== X-Gm-Message-State: AGi0PubXYWd6pNPNYXFlZ4Ci8IWH0ATZI5BzvO5NB3avwhT9R8apZ3q6 Z2jz4rjtm4JwKUcp1A/0qF5qHQ== X-Google-Smtp-Source: APiQypJMT91gyGOFVFMyNAQpk9JYFZPB6mPoQY3NgFMCtGgrZU0eeYoljY3isyq4Cx4LzN1PfTBmsg== X-Received: by 2002:a37:9cce:: with SMTP id f197mr21524601qke.35.1588004306624; Mon, 27 Apr 2020 09:18:26 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id k184sm5619189qke.93.2020.04.27.09.18.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 09:18:25 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 4B826800901; Mon, 27 Apr 2020 11:18:23 -0500 (CDT) Date: Mon, 27 Apr 2020 11:18:23 -0500 From: Justin Pryzby To: Tom Lane Cc: Konstantin Knizhnik , Richard Guo , Thomas Munro , Alvaro Herrera , pgsql-hackers@lists.postgresql.org Subject: Re: weird hash plan cost, starting with pg10 Message-ID: <20200427161823.GY28974@telsasoft.com> References: <20200323165059.GA24950@alvherre.pgsql> <18131.1584982859@sss.pgh.pa.us> <4751e4df-5f98-657e-fb88-c039dd1e7a31@postgrespro.ru> <31321.1586549487@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31321.1586549487@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Apr 10, 2020 at 04:11:27PM -0400, Tom Lane wrote: > I'm not sure it's worth any risk though. A much simpler > fix is to make sure we clear the dangling hashtable pointer, as in > 0002 below (a simplified form of Konstantin's patch). The net > effect of that is that in the case where a hash table is destroyed > and never rebuilt, EXPLAIN ANALYZE would report no hash stats, > rather than possibly-garbage stats like it does today. That's > probably good enough, because it should be an uncommon corner case. > > Thoughts? Checking if you're planning to backpatch this ? > diff --git a/src/backend/executor/nodeHashjoin.c b/src/backend/executor/nodeHashjoin.c > index c901a80..9e28ddd 100644 > --- a/src/backend/executor/nodeHashjoin.c > +++ b/src/backend/executor/nodeHashjoin.c > @@ -1336,6 +1336,12 @@ ExecReScanHashJoin(HashJoinState *node) > else > { > /* must destroy and rebuild hash table */ > + HashState *hashNode = castNode(HashState, innerPlanState(node)); > + > + /* for safety, be sure to clear child plan node's pointer too */ > + Assert(hashNode->hashtable == node->hj_HashTable); > + hashNode->hashtable = NULL; > + > ExecHashTableDestroy(node->hj_HashTable); > node->hj_HashTable = NULL; > node->hj_JoinState = HJ_BUILD_HASHTABLE; -- Justin