Re: Append with naive multiplexing of FDWs - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Append with naive multiplexing of FDWs
Date
Msg-id CA+hUKGL9Uudf7P+qJoLnwL9Xq+5-pRz-G8QQ8=O0NWoN+Budrw@mail.gmail.com
Whole thread Raw
In response to Re: Append with naive multiplexing of FDWs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Append with naive multiplexing of FDWs  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Fri, Dec 6, 2019 at 9:20 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian <bruce@momjian.us> wrote:
> > I agree with Stephen's request.  We have been waiting for the executor
> > rewrite for a while, so let's just do something simple and see how it
> > performs.
>
> I'm sympathetic to the frustration here, and I think it would be great
> if we could find a way forward that doesn't involve waiting for a full
> rewrite of the executor.  However, I seem to remember that when we
> tested the various patches that various people had written for this
> feature (I wrote one, too) they all had a noticeable performance
> penalty in the case of a plain old Append that involved no FDWs and
> nothing asynchronous. I don't think it's OK to have, say, a 2%
> regression on every query that involves an Append, because especially
> now that we have partitioning, that's a lot of queries.
>
> I don't know whether this patch has that kind of problem. If it
> doesn't, I would consider that a promising sign.

I'll look into that.  If there is a measurable impact, I suspect it
can be avoided by, for example, installing a different ExecProcNode
function.



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Memory-Bounded Hash Aggregation
Next
From: Mark Dilger
Date:
Subject: Re: [Proposal] Level4 Warnings show many shadow vars