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 to
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 the
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 a
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 a
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 devolve
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: do
(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 exists(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 exi
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 mean
> 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 ForeignSca
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 w
11 matches
Mail list logo
