Horton

Re: weird hash plan cost, starting with pg10

Richard Guo <guofenglinux@gmail.com>

View thread View on postgr.es
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>, Thomas Munro <thomas.munro@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-04-14T01:50:39Z
Lists: pgsql-hackers 
On Mon, Apr 13, 2020 at 9:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Richard Guo <guofenglinux@gmail.com> writes:
> > At first I was wondering if we need to check whether HashState.hashtable
> > is not NULL in ExecShutdownHash() before we decide to allocate save
> > space for HashState.hinstrument. And then I convinced myself that that's
> > not necessary since HashState.hinstrument and HashState.hashtable cannot
> > be both NULL there.
>
> Even if the hashtable is null at that point, creating an all-zeroes
> hinstrument struct is harmless.
>

Correct. The only benefit we may get from checking if the hashtable is
null is to avoid an unnecessary palloc0 for hinstrument. But that case
cannot happen though.

Thanks
Richard

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.