From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Jeevan Chalke <jeevan.chalke@enterprisedb.com>
Cc: sean.johnston@edgeintelligence.com, Postgres-Bugs <pgsql-bugs@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Subject: Re: BUG #14890: Error grouping by same column twice using FDW
Date: Fri, 10 Nov 2017 13:44:36 -0500
Message-ID: <9632.1510339476@sss.pgh.pa.us> (raw)
In-Reply-To: <CAFjFpRf6A=G-x6TL0y01iRcjjz9A7=BUa4xdwZ0fbD13RsEnMg@mail.gmail.com>
References: <20171107134948.1508.94783@wrigleys.postgresql.org>
<10660.1510093781@sss.pgh.pa.us>
<CAM2+6=X3CwoJ6LE3AGrDmBh1-zhJVd2WAPGKk0zLqDMfhJYOhQ@mail.gmail.com>
<CAFjFpRf6A=G-x6TL0y01iRcjjz9A7=BUa4xdwZ0fbD13RsEnMg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> On Thu, Nov 9, 2017 at 5:29 PM, Jeevan Chalke
> <jeevan.chalke@enterprisedb.com> wrote:
>> + Remote SQL: SELECT c2, c2 FROM "S 1"."T 1" WHERE ((c2 = 6)) GROUP BY c2, c2
> GROUP BY 1, 2 is changed to GROUP BY c2, c2 which is technically wrong. The
> remote planner will think that both the GROUP BY entries refer to one of the
> (possibly the first) entry in the SELECT clause. That's not what really it is.
Yeah. I'm inclined to think that part of what needs to happen here is for
postgres_fdw to change over to always emitting GROUP BY column-number,
so that the grouping columns are clearly matched up with the tlist entries
it's considering, and the remote parser is certain to build
ressortgrouprefs that match what we thought was happening locally.
As you say, we can probably get away without that as long as we don't push
mutable grouping expressions ... but just because we think a grouping
expression is immutable at our end doesn't necessarily mean that it is at
the far end. Also, in view of the (as yet unfixed) bug discussed in
https://www.postgresql.org/message-id/flat/7dbdcf5c-b5a6-ef89-4958-da212fe10176@iki.fi
there's no hope of extending postgres_fdw to push GROUPING SETS correctly
unless it is able to distinguish textually-equal grouping columns.
> May be we were not explaining this correctly earlier. The sortgrouprefs of
> GROUP BY clause can not be different between those two tlists. The difference
> is really the absence of ORDER BY entries. May be we should add some tests
> where there some entries common between ORDER BY and GROUP BY.
As I alluded to upthread, I suspect that dropping ORDER BY markings from
the tlist is likely to break some cases (that is, the planner may expect
the output of the foreign scan to include those columns). If this isn't
fully exercised by the existing tests then we definitely need more tests.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, ashutosh.bapat@enterprisedb.com, jeevan.chalke@enterprisedb.com, robertmhaas@gmail.com
Subject: Re: BUG #14890: Error grouping by same column twice using FDW
In-Reply-To: <9632.1510339476@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox