Limiting the impact of schema additions/poor queries made by clients on production machines

From: Joshua Berry <yoberi(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Limiting the impact of schema additions/poor queries made by clients on production machines
Date: 2009-10-05 15:04:06
Message-ID: 5ccd53c10910050804x2f3a4074n2cf9f36684faad0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Our shop uses postgres for a dozen installations. The applications
have some realtime performance requirements, and are just good enough
to function properly. The problem is that the clients (owners of the
production servers) are using the same server/database for
customizations that are causing problems with the performance of our
applications.

Example of clients' customizations:
* Large tables with text datatypes that get cast in the queries
* No primary keys, indexes, FK constraints
* Use of external scripts that use count(*) from table where id = x,
in a loop from the script, to determine how to construct more queries
later in the same script.

The clients consider themselves experts and don't take
suggestions/criticism well. If we just go ahead and try to port/change
the scripts ourselves, the old code can come back, clobbering the
changes that we made!

My question is this: how can we limit the resources to
queries/applications other that what we create and deploy? Are there
any pragmatic options in scenarios like this? We prided ourselves in
having an OSS solution, but it seems that it's become a liability.

We use PG 8.3 running on a range on Linux Distos.

Regards,
-Joshua

P.S. I've cross-posted this on stackoverflow; I would love to hear any
stories or practical advice in this area, but I don't want to clutter
the pgsql-general list with non-pg advice. Here's the link:
http://stackoverflow.com/questions/1520645/how-to-limit-the-effect-of-client-modifications-to-production-systems

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2009-10-05 16:00:16 Re: attempted to lock invisible tuple - PG 8.4.1
Previous Message Tom Lane 2009-10-05 14:52:02 Re: Errors regarding transporting database using pg_dump