From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Mark Rofail <markm(dot)rofail(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers-owner(at)postgresql(dot)org, Erik Rijkers <er(at)xs4all(dot)nl> |
Subject: | Re: GSoC 2017: Foreign Key Arrays |
Date: | 2017-07-30 05:26:50 |
Message-ID: | 17185.1501392410@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2017-07-30 08:37:00 | Re: Page Scan Mode in Hash Index |
Previous Message | Tom Lane | 2017-07-30 05:21:28 | Re: PL_stashcache, or, what's our minimum Perl version? |