Re: Append with naive multiplexing of FDWs

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
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-05 20:19:50
Message-ID: CA+TgmoZc6HXhGJ+JSQ6ekcZT4Co-MhDH08wxVy3f9Dtt1TuOrg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2019-12-05 20:55:51 Re: Memory-Bounded Hash Aggregation
Previous Message Robert Haas 2019-12-05 20:14:34 Re: backup manifests