Re: weird hash plan cost, starting with pg10

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>, Richard Guo <guofenglinux@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers@lists.postgresql.org
Date: 2020-04-27T16:18:23Z
Lists: pgsql-hackers
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



Commits

  1. Make EXPLAIN report maximum hashtable usage across multiple rescans.

  2. Clear dangling pointer to avoid bogus EXPLAIN printout in a corner case.

  3. psql: Add tab completion for logical replication

  4. Make the upper part of the planner work by generating and comparing Paths.