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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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