From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Gert van Dijk <gertvdijk(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: FDW does not push down LIMIT & ORDER BY with sharding (partitions) |
Date: | 2019-07-10 09:34:57 |
Message-ID: | CAPmGK14xn2dGqOUdzRr=31WkXiy59+C1scch4D=WPtbokYNR3w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Jul 10, 2019 at 5:48 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Wed, Jul 10, 2019 at 9:38 AM David Rowley
> <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> > In any case, this is not a bug, so we really shouldn't discuss on
> > -bugs. It just seems like a limitation of d50d172e51 to me. The
> > setrefs.c code added in 8edd0e79 always gets rid of the
> > Append/MergeAppend when there's just 1 subnode, so it does not seem
> > that unreasonable that planner code that's called before that could
> > assume that such an Append/MergeAppend path would not make it into the
> > final plan. It could do whatever work that it needs to on the single
> > subpath instead.
>
> I see. Agree that this is not a bug of either of the commits I mentioned.
I think so too.
> However, rather than calling this a limitation of d50d172e51, which
> IIUC was an FDW-specific effort, I'd say that we lack the feature to
> push LIMIT under Append/MergeAppend. If we had that feature, then
> much like in the case of grouping that can be pushed under
> Append/MergeAppend (at least for partitioned tables), we wouldn't need
> do anything special for the single-child cases.
Yeah, that's really what I'm thinking: in other words, partitionwise
limit restriction. I'd like to work on it for PG13 if I have time.
Best regards,
Etsuro Fujita
PS: in the StackExchange site, Gert van Dijk stated this:
Running ANALYZE against the foreign table (on FDW instance). Takes a
huge amount of time; looks like it's full tablescanning the remote
table?
Yeah, that's right; when analyzing a remote table, postgres_fdw
retrieves all rows form the remote table, which would take a long time
if the remote table is large. So I'm planning to work on this issue
for PG13.
From | Date | Subject | |
---|---|---|---|
Next Message | Gert van Dijk | 2019-07-10 09:39:46 | Re: FDW does not push down LIMIT & ORDER BY with sharding (partitions) |
Previous Message | Haribabu Kommi | 2019-07-10 09:08:46 | Re: BUG #15889: PostgreSQL failed to build due to error MSB8020 with MSVC on windows |