Re: Overriding the optimizer
От | Craig A. James |
---|---|
Тема | Re: Overriding the optimizer |
Дата | |
Msg-id | 43A2F011.9050809@modgraph-usa.com обсуждение исходный текст |
Ответ на | Re: Overriding the optimizer (Jaime Casanova <systemguards@gmail.com>) |
Список | pgsql-performance |
Jaime Casanova wrote: >>The context is this - in a busy OLTP system, sometimes a query comes >>through that, for whatever reason (foolishness on my part as a >>developer, unexpected use by a user, imperfection of the optimizer, >>etc.), takes a really long time to run, usually because it table-scans >>one or more large tables. If several of these happen at once, it can >>grind an important production system effectively to a halt. I'd like to >>have a few users/operations get a "sorry, I couldn't find a good way to >>do that" message, rather than all the users find that their system has >>effectively stopped working. > ... > set statement_timeout in postgresql.conf I found it's better to use "set statement_timeout" in the code, rather than setting it globally. Someone else pointed outto me that setting it in postgresql.conf makes it apply to ALL transactions, including VACUUM, ANALYZE and so forth. I put it in my code just around the queries that are "user generated" -- queries that are from users' input. I expect anySQL that I write to finish in a reasonable time ;-). Craig
В списке pgsql-performance по дате отправления: