| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, Greg Stark <gsstark(at)mit(dot)edu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Rod Taylor <pg(at)rbt(dot)ca>, "Bort, Paul" <pbort(at)tmwsystems(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Compression and on-disk sorting |
| Date: | 2006-05-19 07:29:03 |
| Message-ID: | 20060519072903.GA17873@svana.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 18, 2006 at 10:02:44PM -0500, Jim C. Nasby wrote:
> http://jim.nasby.net/misc/compress_sort.txt is preliminary results.
> I've run into a slight problem in that even at a compression level of
> -3, zlib is cutting the on-disk size of sorts by 25x. So my pgbench sort
> test with scale=150 that was producing a 2G on-disk sort is now
> producing a 80M sort, which obviously fits in memory. And cuts sort
> times by more than half.
I'm seeing 250,000 blocks being cut down to 9,500 blocks. That's almost
unbeleiveable. What's in the table? It would seem to imply that our
tuple format is far more compressable than we expected.
Do you have any stats on CPU usage? Memory usage?
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeroen T. Vermeulen | 2006-05-19 07:55:53 | Re: [OT] MySQL is bad, but THIS bad? |
| Previous Message | Dragan Zubac | 2006-05-19 07:10:53 |