Re: Admission Control

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Admission Control
Date: 2010-06-25 20:34:21
Message-ID: 4C24CC7D0200002500032B50@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-06-25 20:42:09 Re: Admission Control
Previous Message Josh Berkus 2010-06-25 20:10:54 Re: Admission Control