Limiting the impact of schema additions/poor queries made by clients on production machines - Mailing list pgsql-general

From Joshua Berry
Subject Limiting the impact of schema additions/poor queries made by clients on production machines
Date
Msg-id 5ccd53c10910050804x2f3a4074n2cf9f36684faad0@mail.gmail.com
Whole thread Raw
Responses Re: Limiting the impact of schema additions/poor queries made by clients on production machines
Re: Limiting the impact of schema additions/poor queries made by clients on production machines
List 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

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Errors regarding transporting database using pg_dump
Next
From: Alvaro Herrera
Date:
Subject: Re: attempted to lock invisible tuple - PG 8.4.1