Re: [PATCHES] Reduce heap tuple header size - Mailing list pgsql-hackers

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@sss.pgh.pa.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@postgresql.org)
> 

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