On Mon, Sep 28, 2020 at 10:35 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > At Sat, 26 Sep 2020 19:45:39 +0900, Etsuro Fujita <etsuro.fuj...@gmail.com> > wrote in > > Your patch (and the original patch by Robert [1]) modified > > ExecAppend() so that it can process local plan nodes while waiting for > > the results from remote queries, which would be also a feature that’s > > not supported by Thomas’ patch, but I’d like to know performance > > results.
> At least, even though theoretically, I think it's obvious that it's > performant to do something than just sitting waitng for the next tuple > to come from abroad. I did a simple test on my laptop: create table t1 (a int, b int, c text); create foreign table p1 (a int, b int, c text) server server1 options (table_name 't1'); create table p2 (a int, b int, c text); insert into p1 select 10 + i % 10, i, to_char(i, 'FM00000') from generate_series(0, 99999) i; insert into p2 select 20 + i % 10, i, to_char(i, 'FM00000') from generate_series(0, 99999) i; analyze p1; vacuum analyze p2; create table pt (a int, b int, c text) partition by range (a); alter table pt attach partition p1 for values from (10) to (20); alter table pt attach partition p2 for values from (20) to (30); set enable_partitionwise_aggregate to on; select a, count(*) from pt group by a; HEAD: 47.734 ms With your patch: 32.400 ms This test is pretty simple, but I think this shows that the mentioned feature would be useful for cases where it takes time to get the results from remote queries. Cool! Best regards, Etsuro Fujita
