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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE SET TABLESPACE and pg_toast
Следующее
От: Mitch Skinner
Дата:
Сообщение: Re: Overriding the optimizer