Skip site navigation (1) Skip section navigation (2)

Re: Scalability in postgres

From: david(at)lang(dot)hm
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Scott Carey <scott(at)richrelevance(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Dimitri <dimitrik(dot)fr(at)gmail(dot)com>, Flavio Henrique Araque Gurgel <flavio(at)4linux(dot)com(dot)br>, Fabrix <fabrixio1(at)gmail(dot)com>, James Mansion <james(at)mansionfamily(dot)plus(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Scalability in postgres
Date: 2009-06-05 04:33:53
Message-ID: alpine.DEB.1.10.0906042132371.11064@asgard (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, 5 Jun 2009, Greg Smith wrote:

> On Thu, 4 Jun 2009, Robert Haas wrote:
>
>> That's because this thread has altogether too much theory and
>> altogether too little gprof.
>
> But running benchmarks and profiling is actual work; that's so much less fun 
> than just speculating about what's going on!
>
> This thread reminds me of Jignesh's "Proposal of tunable fix for scalability 
> of 8.4" thread from March, except with only a fraction of the real-world 
> detail.  There are multiple high-profile locks causing scalability concerns 
> at quadruple digit high user counts in the PostgreSQL code base, finding them 
> is easy.  Shoot, I know exactly where a couple are, and I didn't have to 
> think about it at all--just talked with Jignesh a couple of times, led me 
> right to them.  Fixing them without causing regressions in low client count 
> cases, now that's the hard part.  No amount of theoretical discussion 
> advances that any until you're at least staring at a very specific locking 
> problem you've already characterized extensively via profiling.  And even 
> then, profiling trumps theory every time.  This is why I stay out of these 
> discussions and work on boring benchmark tools instead.

actually, as I see it we are a step before that.

it seems that people are arguing that there is no need to look for and fix 
this sort of thing, on the basis that anyone who trips over these problems 
is doing something wrong to start with and needs to change the behavior of 
their app.

David Lang

In response to

Responses

pgsql-performance by date

Next:From: Mark MielkeDate: 2009-06-05 05:56:08
Subject: Re: Scalability in postgres
Previous:From: davidDate: 2009-06-05 04:29:29
Subject: Re: Scalability in postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group