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@decibel.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?"