Re: Getting sorted data from foreign server for merge join

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Getting sorted data from foreign server for merge join
Date: 2015-11-16 09:47:57
Message-ID: CAFjFpRdDOzOvgt2Nh+ZgOfBkhoFKv26GKyXGYvb4Cw3-Wqk0KA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 9, 2015 at 9:39 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Nov 6, 2015 at 2:03 PM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> > Has anyone taken a close look at what happens if the two sides of
> > the merge join have different implementations of the same collation
> > name? Is there anything we should do to defend against the
> > problem?
>
> The issue of FDWs vs. collations has been thought about to some degree
> (see FDW_COLLATE_NONE/SAFE/UNSAFE), but I don't quite understand that
> stuff in detail> .
> >
>

collations arising from a foreign table's var are considered to be safer
(FDW_COLLATE_SAFE) to push down to the foreign server , since they are
either local default collation or are assumed to be same on foreign and
local server as per user declaration. The onus of making that sure is on
the user who declares particular collation for a foreign table var. As said
upthread, different glibc implementations can cause collation ordering
mismatch, this patch will be susceptible to the same problem as
master/standby problem.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2015-11-16 10:44:29 Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Previous Message Marti Raudsepp 2015-11-16 09:27:52 Re: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change