Date: Fri, 13 Mar 2009 13:15:32 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: 8.4 Performance improvements:  was Re: Proposal of
	tunable fix for scalability of 8.4
In-Reply-To: <49BA5537.8060002@sun.com>
Message-ID: <alpine.GSO.2.01.0903131308540.27393@westnet.com>
References: <C5DDBB25.3333%scott@richrelevance.com> <49B922C0.6050700@sun.com>
	<alpine.GSO.2.01.0903121613270.1925@westnet.com>
	<49BA5537.8060002@sun.com>
User-Agent: Alpine 2.01 (GSO 1184 2008-12-16)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

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@gregsmith.com http://www.gregsmith.com Baltimore, MD