I ran some timing tests to check the performance of varchar() vs char16.
The results of the test indicate that there is no difference in
performance (within the timing scatter of the tests):
char16 vc(16)
0.99s 1.05s 1 row (this measures startup time, not types)
39.29s 39.28s ~65000 rows
The char2,4,8,16 types seem to have no value-added over the
better-supported char(), varchar(), text types; I am considering
removing them from the backend, and instead have the parser
transparently translate the types into varchar() (or char() - I'm not
certain which is a better match for the types) for v6.4. Applications
would not have to be changed.
Comments?
From the logic char(16) would be the correct replacement.
I also support the idea to remove char-char16. The problems I see are:
1. char2-16 does not have the 4 byte var header (this would be good for the char() type too)
2. per definition 'a ' = 'a' for the char type but 'a ' <> 'a' for varchar
Note the correct behavior of postgresql:
test=> select 'a '::char(4) = 'a'::char(4);
?column?
--------
t
(1 row)
test=> select 'a '::varchar(4) = 'a'::varchar(4);
?column?
--------
f
(1 row)
but note the "incorrect" (char-char16 beeing a fixed length type) behavior of the char-char16 code
test=> select 'a '::char4 = 'a'::char4;
?column?
--------
f
(1 row)
so the current char2-16 code behaves more like varchar. I don't know if anybody does
rely on this behavior. If not, I would vote to change the char-char16 with the char()
type and remove the varhdr from char(). I like getting a simple char * into my C function.
(see point 1)
Andreas
