From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Theory of operation of collation patch |
Date: | 2011-03-08 23:00:39 |
Message-ID: | 1017.1299625239@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On mn, 2011-03-07 at 12:52 -0500, Tom Lane wrote:
>> It looks like indcollation is acting as a
>> substitute for including a CollateClause in the index key expression,
>> which doesn't seem like a particularly good tradeoff considering all
>> the overhead you must introduce into the default case.
> Conceptually, this characterization is correct. But assuming you do
> away with the indcollation column and instead create expression indexes
> on (col COLLATE "x"), you'd then have an interesting time matching those
> expressions to expressions in the query when choosing an index.
Hmm ... interesting point, but I think it already doesn't work in all
cases for expression indexes. There is an analogous issue for
binary-compatible datatypes, which we hack around by stripping
RelabelType nodes before doing this type of comparison. Maybe we'll
have to do something similar with CollateClauses. I never much cared
for that hack, though ... wonder if there is a cleaner way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Selena Deckelmann | 2011-03-08 23:44:30 | Re: GSoC 2011 - Mentors? Projects? |
Previous Message | Peter Eisentraut | 2011-03-08 22:58:07 | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |