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