Re: Limit and inherited tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Limit and inherited tables
Date: 2016-01-15 16:30:32
Message-ID: 21490.1452875432@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> writes:
>> This example is lacking indexes on the child tables, which is
>> why the plan shown is about as good as you're going to get.
>> The contents of foo1 and foo2 have to be read in entirety in any
>> case, and sorting them separately is not a win compared to doing
>> a single sort.

> It is true, but not in case of FDW connected to remote host.
> In this case sending large volumes of data through network will be very
> inefficient.

If the FDW isn't providing a sorted path, there is no way to improve the
situation much. You can't just "push the LIMIT", you'd have to push
"ORDER BY ... LIMIT", which will mean that a sort has to happen anyway.
If the remote end can do a fast-start sort efficiently, it should report
that, and then a merge-append plan is just fine.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shulgin, Oleksandr 2016-01-15 16:31:39 Re: Stream consistent snapshot via a logical decoding plugin as a series of INSERTs
Previous Message Tom Lane 2016-01-15 16:26:29 Re: Death by regexp_replace