Re: [PATCHES] Reduce heap tuple header size

OK, we need to vote on this patch. It reduces the tuple header by 4
bytes (11% decrease).

If we apply it, we will not be able to easily use pg_upgrade for 7.3
because the on-disk table format will change.

Votes are:

1) Apply it now
2) Wait until August and see if any other table format changes are made.
3) Delay patch until we have other table format changes.

---------------------------------------------------------------------------

Manfred Koizar wrote:
> On Fri, 14 Jun 2002 10:16:22 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >As I commented before, I am not in favor of this. I don't think that a
> >four-byte savings justifies a forced initdb with no chance of
> >pg_upgrade,
>
> As I don't know other users' preferences, I cannot comment on this.
> I just think that four bytes per tuple can amount to a sum that justifies
> this effort. Disk space is not my argument here, but reduced disk IO is.
>
> >plus significantly slower access to
> >several critical header fields. The tqual.c routines are already
> >hotspots in many scenarios. I believe this will make them noticeably
> >slower.
>
> Significantly slower? I tried to analyze HeapTupleSatisfiesUpdate(),
> as I think it is the most complicated of these Satisfies functions
> (look for the !! comments):
>
>
> So in the worst case we return after having done four more
> compares than without the patch. Note that in the most common
> cases there is no additional cost at all. If you still think
> we have a performance problem here, we could replace GetCmin
> and GetCmax by cheaper macros:
>
> #define HeapTupleHeaderGetCminKnowingThatNotMoved(tup) \
> ( \
> AssertMacro(!((tup)->t_infomask & HEAP_MOVED)),
> ( \
> ((tup)->t_infomask & (HEAP_XMIN_IS_XMAX | HEAP_XMAX_INVALID)) ? \
> (CommandId) (tup)->t_cid \
> : \
> FirstCommandId \
> ) \
> )
>
> thus reducing the additional cost to one t_infomask compare,
> because the Satisfies functions only access Cmin and Cmax,
> when HEAP_MOVED is known to be not set.
>
> OTOH experimenting with a moderatly sized "out of production"
> database I got the following results:
> | pages | pages |
> relkind | count | tuples | before| after | savings
> --------+-------+--------+-------+-------+--------
> i | 31 | 808146 | 8330 | 8330 | 0.00%
> r | 32 | 612968 | 13572 | 13184 | 2.86%
> all | 63 | | 21902 | 21514 | 1.77%
>
> 2.86% fewer heap pages mean 2.86% less disk IO caused by heap pages.
> Considering that index pages tend to benefit more from caching
> we conclude that heap pages contribute more to the overall
> IO load, so the total savings in the number of disk IOs should
> be better than the 1.77% shown in the table above. I think
> this outweighs a few CPU cycles now and then.
>
> Servus
> Manfred
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026