Re: weird hash plan cost, starting with pg10 - Mailing list 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