Re: random_page_cost = 2.0 on Heroku Postgres - Mailing list pgsql-performance

From Jeff Janes
Subject Re: random_page_cost = 2.0 on Heroku Postgres
Date
Msg-id CAMkU=1zzx96FQssKixaBubYCWw6Msf1E-2C18HYPDuDfSBTqwA@mail.gmail.com
Whole thread Raw
In response to Re: random_page_cost = 2.0 on Heroku Postgres  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: random_page_cost = 2.0 on Heroku Postgres
List pgsql-performance
On Thu, Feb 9, 2012 at 5:29 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> On Thu, Feb 9, 2012 at 3:41 PM, Peter van Hardenberg <pvh@pvh.ca> wrote:
>> Hmm, perhaps we could usefully aggregate auto_explain output.
>
> How about something where you run a site at random_page cost of x,
> then y, then z and you do some aggregating of query times in each.  A
> scatter plot should tell you lots.

Is there an easy and unintrusive way to get such a metric as the
aggregated query times?  And to normalize it for how much work happens
to have been doing on at the time?

Without a good way to do normalization, you could just do lots of
tests with randomized settings, to average out any patterns in
workload, but that means you need an awful lot of tests to have enough
data to rely on randomization.  But it would be desirable to do this
anyway, in case the normalization isn't as effective as we think.

But how long should each setting be tested for?  If a different
setting causes certain index to start being used, then performance
would go down until those indexes get cached and then increase from
there.  But how long is long enough to allow this to happen?

Thanks,

Jeff

pgsql-performance by date:

Previous
From: Ofer Israeli
Date:
Subject: Re: Inserts or Updates
Next
From: Joshua Berkus
Date:
Subject: Re: random_page_cost = 2.0 on Heroku Postgres