Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Japin Li <japinli(at)hotmail(dot)com>
Cc: Önder Kalacı <onderkalaci(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
Date: 2024-05-24 08:32:55
Message-ID: CAPmGK17SGVZrrFAZPiLj_fy8GpVDeWMnjOb+A2oBennatr=6oA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On Thu, May 23, 2024 at 11:30 PM Japin Li <japinli(at)hotmail(dot)com> wrote:
> On Thu, 23 May 2024 at 14:54, Önder Kalacı <onderkalaci(at)gmail(dot)com> wrote:
> > I'm also not good at wording, but I have a minor suggestions like the
> > following :
> >
> > /*
> > * Also, the FETCH FIRST/NEXT ... ROW/ROWS WITH TIES clause cannot be
> > pushed down
> > * because:
> > * a) The remote system may have a different understanding of equality,
> > which can
> > * result in varying results, such as non-deterministic collations.
> > * b) We do not have knowledge of the remote server's version
> > * as this clause is only supported for PG13 and above.
> > */

> Thanks for your review! Fixed in v5 patch.

I think it is reasonable to refuse to send WITH TIES, but I am
confused about the comments above. Do we really need to care about a)
here in add_foreign_final_paths()? If the query has WITH TIES, 1) it
must have ORDER BY as well, which determines what additional rows tie
for the last place in the result set, and 2) ORDER BY must already
have been determined to be safe to push down before we get here. So
in that case, if getting here, we can consider that WITH TIES is also
safe to push down (if the remote is v13 or later). No?

Anyway, thank you for working on this issue!

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Alexander 2024-05-24 08:34:34 Re: BUG #18477: A specific SQL query with "ORDER BY ... NULLS FIRST" is performing poorly if an ordering column is n
Previous Message Marcin Barczyński 2024-05-24 08:26:50 Re: BUG #18334: Segfault when running a query with parallel workers