Re: random_page_cost = 2.0 on Heroku Postgres

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: random_page_cost = 2.0 on Heroku Postgres
Дата
Msg-id CAMkU=1zzx96FQssKixaBubYCWw6Msf1E-2C18HYPDuDfSBTqwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: random_page_cost = 2.0 on Heroku Postgres  (Scott Marlowe <scott.marlowe@gmail.com>)
Ответы Re: random_page_cost = 2.0 on Heroku Postgres  (Joshua Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Ofer Israeli
Дата:
Сообщение: Re: Inserts or Updates
Следующее
От: Joshua Berkus
Дата:
Сообщение: Re: random_page_cost = 2.0 on Heroku Postgres