AW: [HACKERS] varchar() vs char16 performance
От | Zeugswetter Andreas |
---|---|
Тема | AW: [HACKERS] varchar() vs char16 performance |
Дата | |
Msg-id | 01BD4D0A.FC8F3FA0@pc9358.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: [HACKERS] varchar() vs char16 performance
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: