>>>>> But it's tough to believe that that accounts for a 3-to-4x
>>>>> slowdown of this query; certainly I don't see much performance
>>>>> difference on the datatypes I tried. What datatypes are your fields,
>>>>> anyway?
>>
>>>> 6.5 takes 0.463s
>>>> 7.0 takes 1.640s
>>>> the field type is CHAR(4)
>>
>> Hmm. I see no more than a few percent difference between 6.5 and
>> current. There's something peculiar going on on your system.
I compiled up current code with profiling enabled (make PROFILE=-pg
if you want to try it), and found that actually nearly all of the
runtime forselect * from comuni union select * from comuni
is spent in the sort step; so I was on the wrong track in guessing
that there might be a performance problem in the new Unique coding.
I am not sure why you're seeing a performance differential for sorting.
Most of the cycles are going to go into bpcharlt(), which ultimately
calls strcoll() if you have USE_LOCALE defined. That's probably not a
very fast operation, but that code's hardly changed at all since 6.5.
It should be the same speed...
Are you sure you compiled both 6.5 and 7.0 the same way (with or without
USE_LOCALE)? Are you sure they're both running under the same locale
setting?
You might also try running the sort entirely in memory (no temp files).
Starting psql withsetenv PGOPTIONS "-S 10000"
(10 meg sort space) should do it. I'd be interested to know how 6.5
and 7.0 stack up for you that way.
regards, tom lane
