jwieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>> the two rows that will be updated have equal sort keys and therefore the
>> sort could legally return them in either order. Does Postgres contain
>> its own sort algorithm for this kind of operation, or does it depend on
>> the system qsort? System library qsorts don't normally guarantee
>> stability for equal keys. It could be that we're looking at a byproduct
>> of some minor implementation difference between the qsorts on my machine
>> and yours. If that's it, though, I'm surprised that I'm the only one
>> reporting a difference in the test's output.
> Could be the reason. createfirstrun() in psort.c is using
> qsort as a first try. Maybe we should add ORDER BY pname,
> sysname to the queries to avoid it.
I think this is the answer then. Some poking around in HP's patch
documentation shows that they modified their version of qsort a while
back:
PHCO_6780:qsort performs very badly on sorted blocks of data- customer found that qsort on a file with 100,000randomly
sortedrecords took seconds, whereas a fileof 100,000 records containing large sorted blockstook over an hour to
sort.qsortneeded to pick an alternate pivot point whendetecting sorted or partially sorted data in orderto improve poor
performance.
So I guess it's not so surprising if HP's qsort has slightly different
behavior on equal-keyed data than everyone else's.
Does anyone object to modifying this regression test to sort the
tuples for display? It seems that only the one query needs to be
changed...
regards, tom lane