Re: Feature Request --- was: PostgreSQL Performance Tuning

Поиск
Список
Период
Сортировка
От Ron
Тема Re: Feature Request --- was: PostgreSQL Performance Tuning
Дата
Msg-id E1Hjgly-0008Mo-Ch@elasmtp-kukur.atl.sa.earthlink.net
обсуждение исходный текст
Ответ на Re: Feature Request --- was: PostgreSQL Performance Tuning  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-performance
The more I think about this thread, the more I'm convinced of 2 things:

1= Suggesting initial config values is a fundamentally different
exercise than tuning a running DBMS.
This can be handled reasonably well by HW and OS snooping.  OTOH,
detailed fine tuning of a running DBMS does not appear to be amenable
to this approach.

So...
2= We need to implement the kind of timer support that Oracle 10g has.
Oracle performance tuning was revolutionized by there being
micro-second accurate timers available for all Oracle operations.
IMHO, we should learn from that.

Only the combination of the above looks like it will really be
successful in addressing the issues brought up in this thread.

Cheers,
Ron Peacetree


At 01:59 PM 4/27/2007, Josh Berkus wrote:
>Dan,
>
> > Exactly..  What I think would be much more productive is to use the
> > great amount of information that PG tracks internally and auto-tune the
> > parameters based on it.  For instance:
>
>*Everyone* wants this.  The problem is that it's very hard code to write
>given the number of variables.  I'm working on it but progress is slow,
>due to my travel schedule.
>
>--
>--Josh
>
>Josh Berkus
>PostgreSQL @ Sun
>San Francisco
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match


В списке pgsql-performance по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: pg_stat_* collection
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Feature Request --- was: PostgreSQL Performance Tuning