pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: James Coleman <jtc331@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash
Date: Tue, 10 Dec 2019 14:49:42 -0500
Message-ID: <8525.1576007382@sss.pgh.pa.us> (raw)
In-Reply-To: <20191210173224.y5vaam6ep7pjmddt@development>
References: <CA+hUKGJVgKknBG69fRyj_NRTjVk5mJqcZ7--uNS2C373Ry7KRg@mail.gmail.com>
	<20191203170704.GA28076@alvherre.pgsql>
	<20191210173224.y5vaam6ep7pjmddt@development>

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> As for the performance impact, I did this:

>    create table dim (id int, val text);
>    insert into dim select i, md5(i::text) from generate_series(1,1000000) s(i);
>    create table fact (id int, val text);
>    insert into fact select mod(i,1000000)+1, md5(i::text) from generate_series(1,25000000) s(i);
>    set max_parallel_workers_per_gather = 0;
>    select count(*) from fact join dim using (id);

> So a perfectly regular join between 1M and 25M table. On my machine,
> this takes ~8851ms on master and 8979ms with the patch (average of about
> 20 runs with minimal variability). That's ~1.4% regression, so a bit
> more than the 0.4% mentioned before. Not a huge difference though, and
> some of it might be due to different binary layout etc.

Hmm ... I replicated this experiment here, using my usual precautions
to get more-or-less-reproducible numbers [1].  I concur that the
patch seems to be slower, but only by around half a percent on the
median numbers, which is much less than the run-to-run variation.

So that would be fine --- except that in my first set of runs,
I forgot the "set max_parallel_workers_per_gather" step and hence
tested this same data set with a parallel hash join.  And in that
scenario, I got a repeatable slowdown of around 7.5%, which is far
above the noise floor.  So that's not good --- why does this change
make PHJ worse?

			regards, tom lane

[1] https://www.postgresql.org/message-id/31686.1574722301%40sss.pgh.pa.us





view thread (55+ messages)  latest in thread

Message-ID: <8525.1576007382@sss.pgh.pa.us>
Permalink:  ../8525.1576007382@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/8525.1576007382@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, tomas.vondra@2ndquadrant.com, alvherre@2ndquadrant.com, thomas.munro@gmail.com, andres@anarazel.de, jtc331@gmail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #16104: Invalid DSA Memory Alloc Request in Parallel Hash
  In-Reply-To: <8525.1576007382@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox