From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | |
Cc: | PostgreSQL Developers List <hackers(at)postgreSQL(dot)org> |
Subject: | Info on Data Storage |
Date: | 1999-06-20 00:45:15 |
Message-ID: | 376C399B.93BE95D5@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
istm that this discussion and the one on the 1GB limit on table
segments could form the basis for a missing chapter on "Data Storage"
in the Admin Guide. Would someone (other than Vadim, who we need to
keep coding! :) please keep following this and related threads and
extract the info for the Admin Guide chapter? It doesn't need to be
very long, perhaps just suggesting how to calculate table storage
size, discussing upper limits (e.g. 32-bit OID), and describing the
table segmentation scheme. There is already a chapter (with more
detail than the AG needs) in the Developer's Guide which should be
updated too.
Anyway, both chapters are enclosed; the originals are also in
doc/src/sgml/{storage,page}.sgml)
All we really need is the info, and I can do the markup if whoever
picks this up doesn't feel comfortable with trying the SGML markup.
Volunteers appreciated...
- Thomas
> > > To have them I need to add tuple id (6 bytes) to heap tuple
> > > header. Are there objections? Though it's not good to increase
> > > tuple header size, subj is, imho, very nice feature...
> > Gee, that's a lot of overhead. We would go from 40 bytes ->46 bytes.
> 40? offsetof(HeapTupleHeaderData, t_bits) is 31...
> Well, seems that we can remove 5 bytes from tuple header.
> 1. t_hoff (1 byte) may be computed - no reason to store it.
> 2. we need in both t_cmin and t_cmax only when tuple is updated
> by the same xaction as it was inserted - in such cases we
> can put delete command id (t_cmax) to t_xmax and set
> flag HEAP_XMAX_THE_SAME (as t_xmin), in all other cases
> we will overwrite insert command id with delete command id
> (no one is interested in t_cmin of committed insert xaction)
> -> yet another 4 bytes (sizeof command id).
> If now we'll add 6 bytes to header then
> offsetof(HeapTupleHeaderData, t_bits) will be 32 and for
> no-nulls tuples there will be no difference at all
> (with/without additional 6 bytes), due to double alignment
> of header. So, the choice is: new feature or more compact
> (than current) header for tuples with nulls.
--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
Attachment | Content-Type | Size |
---|---|---|
storage.sgml | text/html | 177 bytes |
page.sgml | text/html | 4.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-06-20 02:35:53 | Re: [HACKERS] anyone build postgres 6.5 ( or 6.4 ) on IRIX 6.3 lately? |
Previous Message | Thomas Lockhart | 1999-06-20 00:20:20 | Re: [HACKERS] tables > 1 gig |