Skip site navigation (1) Skip section navigation (2)

Re: Another idea for dealing with cmin/cmax

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Another idea for dealing with cmin/cmax
Date: 2006-09-29 15:40:32
Message-ID: 16501.1159544432@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> Dumb question... wouldn't getting down to 20 bytes buy us something?

Only on 32-bit machines, which are getting less interesting as database
servers every day.  (Just last night I was reading somebody opining that
the transition to 64-bit hardware would be effectively complete by 2008
... and he was talking about desktop PCs, not serious iron.)

BTW, the apparently useless byte after the 27- or 23-byte header
actually has some good use: in a table of up to 8 columns, you can
fit a null bitmap there "for free".  In a scheme that took us down
to 20 rather than 19 bytes, even a narrow table would pay the full
maxalign price for having a null.

I'm in favor of combining cmin/cmax/xvac to get us down to 23 bytes,
but I think anything beyond that is going to face a serious problem
of greatly increased cost for diminishing returns.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Henry B. HotzDate: 2006-09-29 15:50:46
Subject: Re: JAVA Support
Previous:From: Tom LaneDate: 2006-09-29 15:19:09
Subject: Re: Backup and restore through JDBC

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group