Re: Theory of operation of collation patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Theory of operation of collation patch
Date
Msg-id 8480.1299520377@sss.pgh.pa.us
Whole thread Raw
In response to Re: Theory of operation of collation patch  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Theory of operation of collation patch
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On mån, 2011-03-07 at 11:43 -0500, Tom Lane wrote:
>> ... I now think that the reason it doesn't
>> obviously fail to fail is that indcollation is dead code, and so is
>> approximately 99% of what you added to the planner, because two
>> expressions that are equal() must necessarily have the same collation
>> property.  Tracking the collation as a separate property of a pathkey
>> is thus a useless activity.  If this conclusion isn't correct, please
>> explain why not.

> I'll have to check into these details, but here is a test case that
> shows that it's doing something with the collation of an index:

[ pokes at it some more... ]  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.

But more to the point, your examples do *not* work for me.  I can
reproduce both failing to use an index that should work, and selecting
an index that doesn't work:

d1u=# CREATE TABLE test (a text);
CREATE TABLE
d1u=# CREATE INDEX test_1 ON test (a);
CREATE INDEX
d1u=# CREATE INDEX test_d ON test (a COLLATE "de_DE");
CREATE INDEX
d1u=# CREATE INDEX test_e ON test (a COLLATE "es_ES");
CREATE INDEX
d1u=# CREATE INDEX test_f ON test (a COLLATE "fr_FR");
CREATE INDEX
d1u=# CREATE INDEX test_fz ON test ((a||'z') COLLATE "fr_FR");
CREATE INDEX
d1u=# explain select * from test order by a;                              QUERY PLAN                               
------------------------------------------------------------------------Index Scan using test_f on test
(cost=0.00..63.90rows=1310 width=32)
 
(1 row)

d1u=# explain select * from test order by a collate "fr_FR";                         QUERY PLAN
 
 
---------------------------------------------------------------Sort  (cost=90.93..94.20 rows=1310 width=32)  Sort Key:
((aCOLLATE "fr_FR"))  ->  Seq Scan on test  (cost=0.00..23.10 rows=1310 width=32)
 
(3 rows)

d1u=# set enable_seqscan TO 0;
SET
d1u=# explain select * from test order by a collate "fr_FR";                                   QUERY PLAN
                    
 
----------------------------------------------------------------------------------Sort
(cost=10000000090.93..10000000094.20rows=1310 width=32)  Sort Key: ((a COLLATE "fr_FR"))  ->  Seq Scan on test
(cost=10000000000.00..10000000023.10rows=1310 width=32)
 
(3 rows)

d1u=# explain select * from test order by a||'z';                                         QUERY PLAN
           
 
-------------------------------------------------------------------------Index Scan using test_fz on test
(cost=0.00..67.18rows=1310 width=32)
 
(1 row)

(This is in a database with encoding utf8 and lc_collate = c)
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: [DOCS] Sync rep doc corrections
Next
From: Thom Brown
Date:
Subject: Re: [DOCS] Column-level trigger doc typo fix