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

Поиск
Список
Период
Сортировка
От Joshua Berry
Тема Limiting the impact of schema additions/poor queries made by clients on production machines
Дата
Msg-id 5ccd53c10910050804x2f3a4074n2cf9f36684faad0@mail.gmail.com
обсуждение исходный текст
Ответы 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
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Errors regarding transporting database using pg_dump
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: attempted to lock invisible tuple - PG 8.4.1