Re: Admission Control

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Admission Control
Дата
Msg-id 4C24CC7D0200002500032B50@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Admission Control  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Josh Berkus <josh@agliodbs.com> wrote:
> Greenplum did this several years ago with the Bizgres project
> However, it [was not] compatible with OLTP workloads.
> the "poor man's admission control" is a waste of time because it
> doesn't actually help performance.  We're basically facing doing
> the hard version, or not bothering.
I think it's premature to assume that without any evidence.  I'm
sure it's possible to create a policy which does more harm than good
for any particular workload; there's no denying that could happen,
but things such as limiting open transactions (as just one example)
might be accomplished at very low cost.  Since I have seen dramatic
performance improvements from restricting this through a connection
pool, I'm inclined to believe there could be benefit from such a
simple policy as this.  The total work memory policy Robert proposed
sounds likely to more than pay for itself by allowing larger
work_mem settings without risking cache flushing or swapping.
One thing that seems clear to me is that the admission policy should
be configurable, so that it can be tuned base on workload.  That
would also be consistent with a "start simple and expand the
capabilities" approach.
C'mon, don't be such a buzz-kill.  Why should Greenplum have all the
fun?  ;-)
-Kevin


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Admission Control
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Admission Control