Josh Berkus <j...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
