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 по дате отправления: