On 10.11.2017 12:15, Ashutosh Bapat wrote:
> Maybe in this thread[1] your described problem are solved through
>> introducing Parallel Append node?
>>
>> 1.
>> https://www.postgresql.org/message-id/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1%2BS%2BvRuUQ%40mail.gmail.com
> You may want to review [2] and [3] as well.
>
> [2] https://www.postgresql.org/message-id/9666.1491295317@localhost
> [3] https://www.postgresql.org/message-id/CAM2+6=V64_xhstVHie0Rz=KPEQnLJMZt_e314P0jaT_oJ9MR8A@mail.gmail.com
Thank you very much for this references.
I applied partition-wise-agg-v6 patches and for partitioned tables it
works perfectly:
shard=# explain select count(*) from orders; QUERY PLAN
--------------------------------------------------------------------------------------- Finalize Aggregate
(cost=100415.29..100415.30rows=1 width=8) -> Append (cost=50207.63..100415.29 rows=2 width=8) -> Partial
Aggregate (cost=50207.63..50207.64 rows=1 width=8) -> Foreign Scan on orders_0 (cost=101.00..50195.13
rows=5000 width=0) -> Partial Aggregate (cost=50207.63..50207.64 rows=1 width=8) -> Foreign
Scanon orders_1 (cost=101.00..50195.13
rows=5000 width=0)
(6 rows)
But I wonder why the same optimization is not applied to normal
inherited table:
shard=# explain select count(*) from base; QUERY PLAN
---------------------------------------------------------------------------------- Aggregate (cost=44087.99..44088.00
rows=1width=8) -> Append (cost=0.00..39079.46 rows=2003414 width=0) -> Seq Scan on base (cost=0.00..0.00
rows=1width=0) -> Seq Scan on derived1 (cost=0.00..14425.00 rows=1000000
width=0) -> Seq Scan on derived2 (cost=0.00..14425.00 rows=1000000
width=0) -> Foreign Scan on derived_fdw (cost=100.00..212.39
rows=3413 width=0)
(6 rows)
Are there some principle problems?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers