Date: Mon, 31 Jul 2017 11:18:05 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Rofail <markm.rofail@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	Robert Haas <robertmhaas@gmail.com>,
	Alexander Korotkov <aekorotkov@gmail.com>,
	David Steele <david@pgmasters.net>,
	Stephen Frost <sfrost@snowman.net>,
	pgsql-hackers-owner@postgresql.org, Erik Rijkers <er@xs4all.nl>
Subject: Re: GSoC 2017: Foreign Key Arrays
Message-ID: <20170731151805.nonu6qwv54ca4qvv@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <17185.1501392410@sss.pgh.pa.us>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > ...  However, when you create an index, you can
> > indicate which operator class to use, and it may not be the default one.
> > If a different one is chosen at index creation time, then a query using
> > COUNT(distinct) will do the wrong thing, because DISTINCT will select
> > an equality type using the type's default operator class, not the
> > equality that belongs to the operator class used to create the index.
> 
> > That's wrong: DISTINCT should use the equality operator that corresponds
> > to the index' operator class instead, not the default one.
> 
> Uh, what?  Surely the semantics of count(distinct x) *must not* vary
> depending on what indexes happen to be available.

Err ...

> I think what you meant to say is that the planner may only choose an
> optimization of this sort when the index's opclass matches the one
> DISTINCT will use, ie the default for the data type.

Um, yeah, absolutely.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers