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
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 |