| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | "Hans-Juergen Schoenig" <postgres(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: XIDs and big boxes again ... |
| Date: | 2008-05-11 16:46:51 |
| Message-ID: | 20230.1210524411@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> ... Keep in mind you're proposing to make everything run 3% slower instead of
> using that 3% i/o bandwidth headroom to run vacuum outside the critical path.
I think that's actually understating the problem. Assuming this is a
64-bit machine (which it had better be, if you want XID to be 64 bits...)
then the effective increase in tuple header size is not just 12 bytes
but 16 bytes, due to alignment padding. Greg's 3% overhead number is
only on-target if your average row width is presently about 530 bytes.
It could easily be a whole lot less than that, and the overhead
proportionally higher.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hans-Juergen Schoenig | 2008-05-11 16:50:42 | Re: XIDs and big boxes again ... |
| Previous Message | David Fetter | 2008-05-11 16:32:01 | Re: Setting a pre-existing index as a primary key |