Re: weird hash plan cost, starting with pg10

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