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

Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Date: 2009-03-13 17:15:32
Message-ID: alpine.GSO.2.01.0903131308540.27393@westnet.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, 13 Mar 2009, Jignesh K. Shah wrote:

> I can use dbt2, dbt3 tests to see how 8.4 performs and compare it with 
> 8.3?

That would be very helpful.  There's been some work at updating the DTrace 
capabilities available too; you might compare what that's reporting too.

> * Visibility map - Reduce Vacuum overhead - (I think I can time vacuum with 
> some usage on both databases)

The reduced vacuum overhead should show up as just better overall 
performance.  If you can seperate out the vacuum specific time that would 
be great, I don't know that it's essential.  If the changes don't just 
make a plain old speed improvement in your tests that would be a problem 
worth reporting.

> * Parallel pg_restore (Can be tested with a big database dump)

It would be particularly useful if you could throw some of your 32+ core 
systems at a parallel restore of something with a bunch of tables.  I 
don't think there have been (m)any tests of that code on Solaris or with 
that many restore workers yet.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD


In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2009-03-13 17:16:44
Subject: Re: Proposal of tunable fix for scalability of 8.4
Previous:From: Scott CareyDate: 2009-03-13 16:54:01
Subject: Re: Proposal of tunable fix for scalability of 8.4

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