On Mon, Oct 02, 2006 at 10:52:48AM +0900, ITAGAKI Takahiro wrote: > Tom Lane <[EMAIL PROTECTED]> wrote: > > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > > Dumb question... wouldn't getting down to 20 bytes buy us something? > > > > 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. > > We may use "free" bytes for other purposes. For example, if we increase > the size of XIDs from 4 to 6 bytes, we can get rid of transaction > wraparound problem. There may be some other uses. > > > > 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. > > If we really want to reduce the size of headers to 16 bytes, > we maybe need to do with HeapTupleHeaderData.t_ctid . > > Under the assumption that tuples are offen updated in the same page, > we only need offsets in the page to link an old tuple to new one. > We can reduce the size of t_ctid from 6 to 2 bytes. When tuples > are updated to other pages, we probably need "phantom ctid". > > In another assumption that tuples are offen updated after frozen, > we can overlap ctid and xmin to a physical field using union. > But "phantom xids" are needed to update unfrozen tuples. > > However, I think both assumptions have less probability than > the one assumed when we introduce phantom cids. > The above ideas probably do not work well.
Well, for data warehousing, phantom XIDs of some sort would probably be extremely valuable. Instead of a number of 4 byte XIDs in each tuple, place a limit on the number of transactions that can be live in a table at once. Granted, this means the need to vacuum-freeze more often, but since that can be done as a low-load, low-priority background process that doesn't seem too horrible. If the same technique was applied to cmin/cmax, you could shrink all the visibility info to 1 byte if you wanted to. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
