pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andrey V. Lepikhov <a.lepikhov@postgrespro.ru>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Date: Mon, 26 Apr 2021 11:01:12 +0500
Message-ID: <30f3bf64-7a40-5d19-5b20-94c4365cbc65@postgrespro.ru> (raw)
In-Reply-To: <CAPmGK17O6fMfX84wWfypLWAO4NvD4fgDhm--oyzZ97YP+TxckA@mail.gmail.com>
References: <CAPmGK14igABfEruPPh1X=9KnjY=LquRHQij48oATSo1vWr7yOg@mail.gmail.com>
	<CAPmGK15xtFk2gb9-2b24mFtYBVWoGkmCPFPkM9RHpKVXGLk=sw@mail.gmail.com>
	<CAPmGK178d9-+aFgYorOY4n0pZmZ55WpQ7i1JcCagovYzAh+ueg@mail.gmail.com>
	<20210331.101137.148208859959175708.horikyota.ntt@gmail.com>
	<CAPmGK17T9Swy2FHZk4AVVKNzRxVnd96PX-18DSC2jeDXWNiBoQ@mail.gmail.com>
	<CAPmGK1637W30Wx3MnrReewhafn6F_0J76mrJGoFXFnpPq4QfvA@mail.gmail.com>
	<CAPmGK17O6fMfX84wWfypLWAO4NvD4fgDhm--oyzZ97YP+TxckA@mail.gmail.com>

On 4/23/21 8:12 AM, Etsuro Fujita wrote:
> I have committed the patch.
While studying the capabilities of AsyncAppend, I noticed an 
inconsistency with the cost model of the optimizer:

async_capable = off:
--------------------
Append  (cost=100.00..695.00 ...)
    ->  Foreign Scan on f1 part_1  (cost=100.00..213.31 ...)
    ->  Foreign Scan on f2 part_2  (cost=100.00..216.07 ...)
    ->  Foreign Scan on f3 part_3  (cost=100.00..215.62 ...)

async_capable = on:
-------------------
Append  (cost=100.00..695.00 ...)
    ->  Async Foreign Scan on f1 part_1  (cost=100.00..213.31 ...)
    ->  Async Foreign Scan on f2 part_2  (cost=100.00..216.07 ...)
    ->  Async Foreign Scan on f3 part_3  (cost=100.00..215.62 ...)


Here I see two problems:
1. Cost of an AsyncAppend is the same as cost of an Append. But 
execution time of the AsyncAppend for three remote partitions has more 
than halved.
2. Cost of an AsyncAppend looks as a sum of the child ForeignScan costs.

I haven't ideas why it may be a problem right now. But I can imagine 
that it may be a problem in future if we have alternative paths: complex 
pushdown in synchronous mode (a few rows to return) or simple 
asynchronous append with a large set of rows to return.

-- 
regards,
Andrey Lepikhov
Postgres Professional





view thread (130+ messages)  latest in thread

Message-ID: <30f3bf64-7a40-5d19-5b20-94c4365cbc65@postgrespro.ru>
Permalink:  ../30f3bf64-7a40-5d19-5b20-94c4365cbc65@postgrespro.ru/
Also on:    postgresql.org/message-id/30f3bf64-7a40-5d19-5b20-94c4365cbc65@postgrespro.ru

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: a.lepikhov@postgrespro.ru, etsuro.fujita@gmail.com, horikyota.ntt@gmail.com, pryzby@telsasoft.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Asynchronous Append on postgres_fdw nodes.
  In-Reply-To: <30f3bf64-7a40-5d19-5b20-94c4365cbc65@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox