Jan Wieck wrote:
> Tom Lane wrote:
> >
> > Jan Wieck <JanWieck@Yahoo.com> writes:
> > > Do we have any hard numbers on that? Is it just access to the header
> > > fields, or do we loose the offset cacheability of all fixed size fields
> > > at the beginning of a row? In the latter case count me into the
> > > slowness-believer camp.
> >
> > I don't believe the patch would have made the header variable size,
> > only changed what the fixed size is. The slowdown I was worried about
> > was just a matter of a couple extra tests and branches in the tqual.c
> > routines; which would be negligible if they weren't such hotspots.
>
> Did someone run at least pgbench with/without that patch applied?
No, but he did perform this analysis:
> 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.
--
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, Pennsylvania 19026
