On Sat, May 25, 2019 at 2:19 AM Sean Johnston
wrote:
> Obviously this isn't mainstream postgres but just wondering if anyone has
> looked into issues with regards to pushing order/limit to remote nodes for
> fdw.
In PostgreSQL 12 Beta 1 released this week [1], we can push down ORDER
BY/LIMIT
Sean Johnston writes:
> Not sure if this is the right avenue to follow up on this. The patch works
> fine. However, we're working on a modified version of the postgres_fdw in
> which we're trying to push as much as possible to the remote nodes,
> including ordering and limits. The patch causes
Not sure if this is the right avenue to follow up on this. The patch works
fine. However, we're working on a modified version of the postgres_fdw in
which we're trying to push as much as possible to the remote nodes,
including ordering and limits. The patch causes the upper paths for the
ordering
Etsuro Fujita writes:
> On Sat, Apr 27, 2019 at 2:10 AM Tom Lane wrote:
>> If we don't want to change what the core code does with fdw_exprs,
>> I think the only way to fix it is to hack postgres_fdw so that it
>> won't generate plans involving the problematic case.
> Seems reasonable.
>> See
On Sat, Apr 27, 2019 at 2:10 AM Tom Lane wrote:
> > (2019/04/26 3:24), Tom Lane wrote:
> >> If we do leave it like this, then the only way for postgres_fdw to
> >> avoid trouble is to not have any entries in fdw_exprs that exactly
> >> match entries in fdw_scan_tlist. So that pretty much
Etsuro Fujita writes:
> (2019/04/26 3:24), Tom Lane wrote:
>> If we do leave it like this, then the only way for postgres_fdw to
>> avoid trouble is to not have any entries in fdw_exprs that exactly
>> match entries in fdw_scan_tlist. So that pretty much devolves back
>> to what I said before:
(2019/04/26 3:24), Tom Lane wrote:
PG Bug reporting form writes:
[ this crashes if ft4 is a postgres_fdw foreign table: ]
select exists(select c1 from ft4), avg(c1) from ft4 where c1 = (select
max(c1) from ft4);
Hm, the max() subquery isn't necessary, this is sufficient:
select
I wrote:
> Well, that's just coincidental for the case where the problem fdw_expr is
> a Param. I haven't tried to figure out exactly what upper-path generation
> thinks it should put into fdw_exprs, but is it really only Params?
Oh, this is interesting:
regression=# explain verbose
select
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Thu, Apr 25, 2019 at 8:24 PM Tom Lane wrote:
>> The proximate cause of the crash is that we have {PARAM 1}
>> (representing the output of the InitPlan) in the path's fdw_exprs, and
>> also the identical expression in fdw_scan_tlist, and that
> On Thu, Apr 25, 2019 at 8:24 PM Tom Lane wrote:
>
> The proximate cause of the crash is that we have {PARAM 1}
> (representing the output of the InitPlan) in the path's fdw_exprs, and
> also the identical expression in fdw_scan_tlist, and that means that when
> setrefs.c processes the
PG Bug reporting form writes:
> [ this crashes if ft4 is a postgres_fdw foreign table: ]
> select exists(select c1 from ft4), avg(c1) from ft4 where c1 = (select
> max(c1) from ft4);
Hm, the max() subquery isn't necessary, this is sufficient:
select exists(select c1 from ft4), avg(c1) from ft4
11 matches
Mail list logo
