Re: Append with naive multiplexing of FDWs

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Append with naive multiplexing of FDWs
Date: 2019-12-09 17:18:44
Message-ID: 20191209171844.GA5192@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 5, 2019 at 03:19:50PM -0500, Robert Haas wrote:
> On Thu, Dec 5, 2019 at 1:12 PM Bruce Momjian <bruce(at)momjian(dot)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.

Certainly any overhead on normal queries would be unacceptable.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-12-09 17:21:20 Re: Questions about PostgreSQL implementation details
Previous Message Finnerty, Jim 2019-12-09 17:05:39 Re: Corruption with duplicate primary key