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
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 |