From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Hubert Lubaczewski <depesz(at)depesz(dot)com>, pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: explain analyze output with parallel workers - question about meaning of information for explain.depesz.com |
Date: | 2017-12-08 19:54:49 |
Message-ID: | CA+TgmoZiE=Gs=CBtufrNSFWAqe6dGEoEfUQg_pwXhcFXxpwCyw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 8, 2017 at 5:11 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> Okay, I have adjusted the patch accordingly. I have also added a
>> regression test which should produce the same result across different
>> runs, see if that looks okay to you, then it is better to add such a
>> test as well.
>
> The regression test added by patch needs cleanup at the end which I
> have added in the attached patch.
Hmm. If we're going this way, then shouldn't we revert the changes
commit 2c09a5c12a66087218c7f8cba269cd3de51b9b82 made to
ExecParallelRetrieveInstrumentation? If that function is only ever
called once, then there's no point doing InstrInit + InstrAgg node, or
checking whether worker_instrument is already initialized. We can
just palloc + memcpy as the code did previously.
I think.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-12-08 20:12:42 | Re: [HACKERS] Custom compression methods |
Previous Message | Andres Freund | 2017-12-08 19:48:54 | Re: Is it possible and worthy to optimize scanRTEForColumn()? |