From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improving executor performance |
Date: | 2016-06-29 18:32:54 |
Message-ID: | 20160629183254.frcm3dgg54ud5m6o@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2016-06-28 10:01:28 +0000, Rajeev rastogi wrote:
> >3) Our 1-by-1 tuple flow in the executor has two major issues:
>
> Agreed, In order to tackle this IMHO, we should
> 1. Makes the processing data-centric instead of operator centric.
> 2. Instead of pulling each tuple from immediate operator, operator can push the tuple to its parent. It can be allowed to push until it sees any operator, which cannot be processed without result from other operator.
> More details from another thread:
> https://www.postgresql.org/message-id/BF2827DCCE55594C8D7A8F7FFD3AB77159A9B904@szxeml521-mbs.china.huawei.com
I doubt that that's going to be ok in the generic case (memory usage,
materializing too much, "bushy plans", merge joins), and it's way more
invasive than what I'm thinking of. I think by having batches of tuples
"bubble" up in a vulcano style executor, it's possible to get most of
the improvements of both approaches.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-06-29 18:39:26 | Re: An unkillable connection caused replication delay on my replica |
Previous Message | Alvaro Herrera | 2016-06-29 18:17:50 | Re: primary_conninfo missing from pg_stat_wal_receiver |