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

Re: Reduce heap tuple header size

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Manfred Koizar <mkoi-pg(at)aon(dot)at>,pgsql-patches(at)postgresql(dot)org
Subject: Re: Reduce heap tuple header size
Date: 2002-06-25 13:38:52
Message-ID: 200206251338.g5PDcqk06205@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Jan, any update on this?  Are the numbers correct?

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

Jan Wieck wrote:
> Bruce Momjian wrote:
> > 
> > Jan Wieck wrote:
> > >
> > > 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.
> 
> This anawhat? This is a proof that this patch is able to save not even
> 3% of disk space in a production environment plus an assumption that the
> saved IO outweights the extra effort in the tuple visibility checks.
> 
> Here are some numbers:
> 
> P3 850MHz 256MB RAM IDE
> postmaster -N256 -B8192
> pgbench -i -s 10 db
> pgbench -c 20 -t 500 db
> 
> 
> Current CVS tip:     tps  34.1, 38.7, 36.6
>                  avg(tps) 36.4
> 
> With patch:          tps  37.0, 41.1, 41.1
>                  avg(tps) 39.7
> 
> So it saves less than 3% disk space at the cost of about 9% performance
> loss. If we can do the same the other way around I'd go for wasting some
> more disk space.
> 
> 
> Jan
> 
> -- 
> 
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #================================================== JanWieck(at)Yahoo(dot)com #
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go 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



In response to

Responses

pgsql-hackers by date

Next:From: Curt SampsonDate: 2002-06-25 13:52:14
Subject: Re: Buffer Management
Previous:From: Bruce MomjianDate: 2002-06-25 13:22:05
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE

pgsql-patches by date

Next:From: Neil ConwayDate: 2002-06-25 14:11:16
Subject: Re: several minor cleanups
Previous:From: Andrew SullivanDate: 2002-06-25 12:31:45
Subject: Re: Some Solaris notes, and an invitation

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