From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: auto_explain vs. parallel query |
Date: | 2016-11-03 16:39:38 |
Message-ID: | CA+TgmoarqsNiUQ+rQiUg9rwpSvvmzibyqi_SE7wxuKiphsbTPg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 3, 2016 at 12:11 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> Sure, the Gather node creates it. There's generally only one per
>> query, though, and that's how most information is communicated from
>> leader to workers.
>
> Ah, right. I haven't realized there's just a single Gather per query.
That's not a hard and fast rule; it just usually works out that way.
>> Yeah. I thought that there wouldn't be any reason for third-party
>> code to need to get into these segments, but maybe that was
>> short-sighted of me. If we fix this without that, then we've got to
>> force pg_stat_statements to be loaded through
>> shared_preload_libarries, as you mentioned, and that doesn't seem nice
>> either.
>
> Well, I was talking about auto_explain, and pg_stat_statements already has
> to be loaded through shared_preload_libraries. I'm not sure how many other
> extensions would need similar hack (I don't see any in contrib, but there
> may be external ones).
Sorry, auto_explain, then.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2016-11-03 16:44:11 | Re: Applying XLR_INFO_MASK correctly when looking at WAL record information |
Previous Message | Robert Haas | 2016-11-03 16:37:21 | Re: Declarative partitioning - another take |