| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, 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-17 15:57:24 |
| Message-ID: | 20624.1147881444@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> On Wed, May 17, 2006 at 11:38:05AM -0400, Tom Lane wrote:
>> Note that a large part of the reason for the current logtape.c design
>> is to avoid requiring 2X or more disk space to sort X amount of data.
> Actually, I suspect in most cases it won't matter; I don't think people
> make a habit of trying to sort their entire database. :)
Well, some years ago we used something like 4X space to sort X amount of
data (this is the native behavior of 7-way polyphase merge, it turns out)
and we got yelled at. Which is what prompted the writing of logtape.c.
Maybe disk space has gotten so cheap since then that it no longer
matters ... but I suspect the nature of DB applications is that people
are always pushing the envelope of what their hardware can do.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2006-05-17 16:00:28 | Re: Foreign key column reference ordering and information_schema |
| Previous Message | Stephan Szabo | 2006-05-17 15:54:08 | Re: Foreign key column reference ordering and information_schema |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2006-05-17 16:12:47 | Re: [GENERAL] Querying libpq compile time options |
| Previous Message | Jim C. Nasby | 2006-05-17 15:45:04 | Re: Compression and on-disk sorting |