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
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 |