> I have compared current with 6.5 using 1000000 tuple-table (243MB) (I
> wanted to try 2GB+ table but 6.5 does not work in this case). The
> result was strange in that current is *faster* than 6.5!
> 
> RAID5
> 	current	2:29
> 	6.5.2	3:15
> 
> non-RAID
> 	current	1:50
> 	6.5.2	2:13
> 
> Seems my previous testing was done in wrong way or the behavior of
> sorting might be different if the table size is changed?

This new test case is not big enough to show cache memory contention,
and is thus faster with the new code.
The 2 Gb test case was good, because it shows what happens when 
cache memory becomes rare.

Andreas

Tue, 2 Nov 1999 10:50:22 +0100 
Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
AW: [HACKERS] sort on huge table 
Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at> writes:
> This new test case is not big enough to show cache memory contention,
> and is thus faster with the new code.

Cache memory contention?  I don't think so.  Take a look at the CPU
versus elapsed times in Tatsuo's prior report on the 2Gb case.
I'm not sure yet what's going on, but it's clear that the bottleneck is
I/O operations not processor/memory speed.

			regards, tom lane

Tue, 02 Nov 1999 10:23:26 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: [HACKERS] sort on huge table 