On Tue, Jul 19, 2005 at 11:48:16AM +0200, Martijn van Oosterhout wrote:
> int, bool, bool 6 bytes, no padding
> bool, int, bool 9 bytes, including 3 bytes padding
> bool, bool, int 8 bytes, including 2 bytes padding
We store bool's in a byte and don't compact? That would be another very
handy change... the first 8 bools in a table all use one byte, the next
8 use another, etc.
> Assuming an int is 4 bytes. If it's 8-bytes it's even more obvious.
>
> I think it would be a really good for postgresql to reorder the fields
> in the background (on disk, not in select * statements).
I believe the last time this was discussed the consensus was that we
should first have a way for users to do this manually, since the backend
would need most of that framework anyway. I don't know that much (if
any) work has been done on this.
One of the advantages of divorcing the in-memory page layout from the
on-disk page layout is that by doing so you get even more benefit from
re-ordering fields, and it's not dependant on figuring out how to
present fields in a different order than how they're stored in the page.
The downside is that it doesn't get you some of the in-memory benefits
that field ordering will get you, but I suspect in most cases the
on-disk gains will swamp those out anyway.
Does anyone have any idea what it would take to hack in divorcing disk
page layout from memory layout just for testing?
--
Jim C. Nasby, Database Consultant decibel@xxxxxxxxxxx
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?"
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
