Re: weird hash plan cost, starting with pg10

On Mon, Apr 27, 2020 at 12:26:03PM -0400, Tom Lane wrote: > Justin Pryzby writes: > > Checking if you're planning to backpatch this ? > > Are you speaking of 5c27bce7f et al? Oops, yes, thanks. I updated wiki/PostgreSQL_13_Open_Items just now. -- Justin

Re: weird hash plan cost, starting with pg10

Justin Pryzby writes: > Checking if you're planning to backpatch this ? Are you speaking of 5c27bce7f et al? regards, tom lane

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

Re: weird hash plan cost, starting with pg10

On Mon, Apr 13, 2020 at 9:53 PM Tom Lane wrote: > Richard Guo 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

Re: weird hash plan cost, starting with pg10

Richard Guo 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

Re: weird hash plan cost, starting with pg10

On Sat, Apr 11, 2020 at 4:11 AM Tom Lane wrote: > Konstantin Knizhnik writes: > > On 25.03.2020 13:36, Richard Guo wrote: > >> I tried this recipe on different PostgreSQL versions, starting from > >> current master and going backwards. I was able to reproduce this issue > >> on all versions

Re: weird hash plan cost, starting with pg10

Konstantin Knizhnik writes: > On 25.03.2020 13:36, Richard Guo wrote: >> I tried this recipe on different PostgreSQL versions, starting from >> current master and going backwards. I was able to reproduce this issue >> on all versions above 8.4. In 8.4 version, we do not output information >> on

Re: weird hash plan cost, starting with pg10

On 25.03.2020 13:36, Richard Guo wrote: On Tue, Mar 24, 2020 at 3:36 PM Richard Guo > wrote: On Tue, Mar 24, 2020 at 11:05 AM Thomas Munro mailto:thomas.mu...@gmail.com>> wrote: I think there might be a case like this: *

Re: weird hash plan cost, starting with pg10

On Tue, Mar 24, 2020 at 3:36 PM Richard Guo wrote: > On Tue, Mar 24, 2020 at 11:05 AM Thomas Munro > wrote: > >> >> I think there might be a case like this: >> >> * ExecRescanHashJoin() decides it can't reuse the hash table for a >> rescan, so it calls ExecHashTableDestroy(), clears

Re: weird hash plan cost, starting with pg10

On Tue, Mar 24, 2020 at 11:05 AM Thomas Munro wrote: > On Tue, Mar 24, 2020 at 9:55 AM Thomas Munro > wrote: > > On Tue, Mar 24, 2020 at 6:01 AM Tom Lane wrote: > > > Alvaro Herrera writes: > > > > While messing with EXPLAIN on a query emitted by pg_dump, I noticed > that > > > > current

Re: weird hash plan cost, starting with pg10

On Mon, Mar 23, 2020 at 01:50:59PM -0300, Alvaro Herrera wrote: > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > current Postgres 10 emits weird bucket/batch/memory values for certain > hash nodes: > > -> Hash (cost=0.11..0.11 rows=10

Re: weird hash plan cost, starting with pg10

On Tue, Mar 24, 2020 at 9:55 AM Thomas Munro wrote: > On Tue, Mar 24, 2020 at 6:01 AM Tom Lane wrote: > > Alvaro Herrera writes: > > > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > > > current Postgres 10 emits weird bucket/batch/memory values for certain > > > hash

Re: weird hash plan cost, starting with pg10

On Tue, Mar 24, 2020 at 6:01 AM Tom Lane wrote: > Alvaro Herrera writes: > > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > > current Postgres 10 emits weird bucket/batch/memory values for certain > > hash nodes: > > > -> Hash

Re: weird hash plan cost, starting with pg10

Alvaro Herrera writes: > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > current Postgres 10 emits weird bucket/batch/memory values for certain > hash nodes: > -> Hash (cost=0.11..0.11 rows=10 width=12) (actual > time=0.002..0.002 rows=1

weird hash plan cost, starting with pg10

Hello While messing with EXPLAIN on a query emitted by pg_dump, I noticed that current Postgres 10 emits weird bucket/batch/memory values for certain hash nodes: -> Hash (cost=0.11..0.11 rows=10 width=12) (actual time=0.002..0.002 rows=1 loops=8)