| From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Per tuple overhead, cmin, cmax |
| Date: | 2002-05-03 07:51:46 |
| Message-ID: | ejf4du853mblm44f0u78f02g166r69lng7@4ax.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 02 May 2002 21:10:40 -0400, Tom Lane wrote:
>Hmm ... that might work. Actually, we are trying to stuff *five*
>numbers into these fields: xmin, xmax, cmin, cmax, and a VACUUM FULL
>transaction id (let's call it xvac just to have a name). The code
>currently assumes that cmin is not interesting simultaneously with xvac.
>I think it might be true that cmax is not interesting simultaneously
>with xvac either, in which case this could be made to work. (Vadim,
>your thoughts?)
Having read the sources recently I'm pretty sure you're right.
>I'm on the fence about it. My thoughts are probably colored by the
>fact that I prefer platforms that have MAXALIGN=8, so half the time
>(including all null-free rows) there'd be no savings at all.
But the other half of the time we'd save 8 bytes. So on average we
get savings of 4 bytes per tuple, don't we?
> Now if
>we could get rid of 8 bytes in the header, I'd get excited ;-)
I keep trying :-)
Servus
Manfred
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bradley Kieser | 2002-05-03 08:11:16 | Re: a vulnerability in PostgreSQL |
| Previous Message | Manfred Koizar | 2002-05-03 07:37:25 | Trying to reduce per tuple overhead (bitmap) |