Greg Smith wrote:
On Thu, 12 Mar 2009, Jignesh K. Shah wrote:
As soon as I get more "cycles" I will try variations of it but it
would help if others can try it out in their own environments to see
if it helps their instances.
What you should do next is see whether you can remove the bottleneck
your test is running into via using a connection pooler. That's what
I think most informed people would do were you to ask how to setup an
optimal environment using PostgreSQL that aimed to serve thousands of
clients. If that makes your bottleneck go away, that's what you should
be recommending to customers who want to scale in this fashion too.
If the bottleneck moves to somewhere else, that new hot spot might be
one people care more about. Given that there are multiple good
pooling solutions floating around already, it's hard to justify
dumping coding and testing resources here if that makes the problem
move somewhere else.
It's great that you've identified an alternate scheduling approach
that helps on your problematic test case, but you're a long ways from
having a full model of how changes to the locking model impact other
database workloads. As for the idea of doing something in this area
for 8.4, there are a significant number of performance-related changes
already committed for that version that deserve more focused testing
during beta. You're way too late to throw another one into that
already crowded area.
On the other hand I have taken up a task of showing 8.4 Performance
improvements over 8.3.
Can we do a vote on which specific performance features we want to test?
I can use dbt2, dbt3 tests to see how 8.4 performs and compare it with
8.3? Also if you have your own favorite test to test it out let me
know.. I have allocated some time for this task so it is feasible for me
to do this.
Many of the improvements may not be visible through this standard tests
so feedback on testing methology for those is also appreciated.
* Visibility map - Reduce Vacuum overhead - (I think I can time vacuum
with some usage on both databases)
* Prefetch IO with posix_fadvice () - Though I am not sure if it is
supported on UNIX or not (but can be tested by standard tests)
* Parallel pg_restore (Can be tested with a big database dump)
Any more features that I can stress during the testing phase?
Regards,
Jignesh
--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Jignesh Shah http://blogs.sun.com/jkshah
The New Sun Microsystems,Inc http://sun.com/postgresql
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
