On Thu, Jul 14, 2005 at 11:29:23PM +0200, Martijn van Oosterhout wrote:
> On Thu, Jul 14, 2005 at 11:30:36AM -0500, Jim C. Nasby wrote:
> > On Wed, Jul 13, 2005 at 07:52:04PM -0400, Bruce Momjian wrote:
> > > This is a good point. We have always stored data on disk that exactly
> > > matches its layout in memory. We could change that, but no one has
> > > shown it would be a win.
> > Out of curiosity, what would be involved in hacking the backend enough
> > to be able to test this theory out? I'm guessing you'd want to convert
> > between on-disk and in-memory formats as you read pages in, so either
> > on-disk pages would become variable size (and smaller than memory pages)
> > or in-memory pages would become variable size (and larger than on-disk
> > pages).
> It's a pain because on some architectures you can't do unaligned
> accesses. I imagine you'd have to have the on-disk pages in memory and
> copy them to a temporary space when you actually want to use the data,
> converting on the fly.
My thought was to convert as pages were read and written. That should
minimize the code impact.
> IMHO a much much better approach would be the two phase:
> - Decouple order of columns on disk from logical column order
> Then people can rearrange columns, people do ask that occasionally.
> - Change CREATE TABLE to rearrange columns on disk (not the logical
> order) to minimize padding.
> This gives you real benefits without having to overhaul the code...
True, that would be of some benefit, but not as much as being able to
compact the disk storage.
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
In response to
pgsql-general by date
|Next:||From: Marc G. Fournier||Date: 2005-07-15 02:00:15|
|Subject: Re: gborg down|
|Previous:||From: Joe Healy||Date: 2005-07-14 23:28:39|
|Subject: gborg down|