| From: | Zeugswetter Andreas SEV <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'t-ishii(at)sra(dot)co(dot)jp'" <t-ishii(at)sra(dot)co(dot)jp> |
| Cc: | "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | AW: [HACKERS] sort on huge table |
| Date: | 1999-11-02 09:50:22 |
| Message-ID: | 219F68D65015D011A8E000006F8590C60339E15D@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vince Vielhaber | 1999-11-02 11:24:26 | Re: [HACKERS] Backend terminated abnormally |
| Previous Message | Zeugswetter Andreas SEV | 1999-11-02 09:22:40 | Re: [HACKERS] Trigger aborted on error |