Re: FW: Query execution failure

From: Joe Conway <mail(at)joeconway(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pete Storer <Pete(dot)Storer(at)sas(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: FW: Query execution failure
Date: 2023-01-30 16:16:03
Message-ID: f0c0bfec-0571-8711-deee-f6e679846c18@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 1/30/23 10:34, Bruce Momjian wrote:
> On Thu, Jan 26, 2023 at 11:06:41AM -0500, Tom Lane wrote:
>> I don't know anything about the mysql FDW, but another possible route
>> to fixing things is to get it to not believe that the remote's sort
>> ordering matches the local one. If the plan were relying on a local
>> sort instead of a remote sort then everything would be fine.
>
> When we implemented sort pushdown to FDWs I had not considered how hard
> it might be to match sort ordering, especially considering the problem
> we have in matching orderings from different operating system versions.

Different sort ordering could be due to all kinds of things, including
for example a RHEL 8 instance pulling from a RHEL 7 one (glibc mismatch).

Also I have been told (not verified by me) that MySQL at least supports
using its own built-in collation. If so, how can we ever know that
whatever Postgres is using will match that?

I wonder if we should have an attribute of a foreign server that
indicates whether sort pushdown is enabled or not.

--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-01-30 16:29:33 Re: FW: Query execution failure
Previous Message Bruce Momjian 2023-01-30 15:34:20 Re: FW: Query execution failure