pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Smith <gsmith@gregsmith.com>
To: Jignesh K. Shah <J.K.Shah@Sun.COM>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Thu, 12 Mar 2009 16:35:31 -0400 (EDT)
Message-ID: <alpine.GSO.2.01.0903121613270.1925@westnet.com> (raw)
In-Reply-To: <49B922C0.6050700@sun.com>
References: <C5DDBB25.3333%scott@richrelevance.com>
	<49B922C0.6050700@sun.com>

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.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD



view thread (119+ messages)  latest in thread

Message-ID: <alpine.GSO.2.01.0903121613270.1925@westnet.com>
Permalink:  ../alpine.GSO.2.01.0903121613270.1925@westnet.com/
Also on:    postgresql.org/message-id/alpine.GSO.2.01.0903121613270.1925@westnet.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: gsmith@gregsmith.com, J.K.Shah@Sun.COM, scott@richrelevance.com, Kevin.Grittner@wicourts.gov
  Subject: Re: Proposal of tunable fix for scalability of 8.4
  In-Reply-To: <alpine.GSO.2.01.0903121613270.1925@westnet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox