Re: Asynchronous Append on postgres_fdw nodes.
| От | Andrey Lepikhov |
|---|---|
| Тема | Re: Asynchronous Append on postgres_fdw nodes. |
| Дата | |
| Msg-id | a38bb206-8340-9528-5ef6-37de2d5cb1a3@postgrespro.ru обсуждение исходный текст |
| Ответ на | Re: Asynchronous Append on postgres_fdw nodes. (Etsuro Fujita <etsuro.fujita@gmail.com>) |
| Ответы |
Re: Asynchronous Append on postgres_fdw nodes.
|
| Список | pgsql-hackers |
On 6/5/21 11:45, Etsuro Fujita wrote:
> On Tue, Apr 27, 2021 at 9:31 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> The patch fixes the issue, but I don’t think it’s the right way to go,
> because it requires an extra ExecProcNode() call, which wouldn’t be
> efficient. Also, the patch wouldn’t address another issue I noticed
> in EXPLAIN ANALYZE for async-capable nodes that the command wouldn’t
> measure the time spent in such nodes accurately. For the case of
> async-capable node using postgres_fdw, it only measures the time spent
> in ExecProcNode() in ExecAsyncRequest()/ExecAsyncNotify(), missing the
> time spent in other things such as creating a cursor in
> ExecAsyncRequest(). :-(. To address both issues, I’d like to propose
> the attached, in which I added instrumentation support to
> ExecAsyncRequest()/ExecAsyncConfigureWait()/ExecAsyncNotify(). I
> think this would not only address the reported issue more efficiently,
> but allow to collect timing for async-capable nodes more accurately.
Ok, I agree with the approach, but the next test case failed:
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
SELECT * FROM (
(SELECT * FROM f1) UNION ALL (SELECT * FROM f2)
) q1 LIMIT 100;
ERROR: InstrUpdateTupleCount called on node not yet executed
Initialization script see in attachment.
--
regards,
Andrey Lepikhov
Postgres Professional
Вложения
В списке pgsql-hackers по дате отправления: