From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | thomas(dot)munro(at)gmail(dot)com |
Cc: | robertmhaas(at)gmail(dot)com, bruce(at)momjian(dot)us, pgsql-hackers(at)postgresql(dot)org, sfrost(at)snowman(dot)net |
Subject: | Re: Append with naive multiplexing of FDWs |
Date: | 2019-12-06 08:12:11 |
Message-ID: | 20191206.171211.1119526746053895900.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Fri, 6 Dec 2019 10:03:44 +1300, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote in
> On Fri, Dec 6, 2019 at 9:20 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > 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.
Replacing ExecProcNode perfectly isolates additional process in
ExecAppendAsync. Thus, for pure local appends, the patch can impact
performance through only planner and execinit. But I don't believe it
cannot be as large as observable in a large scan.
As the mail pointed upthread, the patch acceleartes all remote cases
when fetch_size is >= 200. The problem was that local scans seemed
slightly slowed down. I dusted off the old patch (FWIW I attached it)
and.. will re-run on the current development environment. (And
re-check the code.).
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Allow-wait-event-set-to-be-registered-to-resource.patch | text/x-patch | 9.3 KB |
v1-0002-infrastructure-for-asynchronous-execution.patch | text/x-patch | 42.3 KB |
v1-0003-async-postgres_fdw.patch | text/x-patch | 55.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2019-12-06 08:21:55 | Re: Removal of support for OpenSSL 0.9.8 and 1.0.0 |
Previous Message | Noah Misch | 2019-12-06 07:57:15 | Re: libpq sslpassword parameter and callback function |