| От | Mark Stosberg |
|---|---|
| Тема | Using statement_timeout as a performance tool? |
| Дата | |
| Msg-id | epssco$jes$1@sea.gmane.org обсуждение исходный текст |
| Список | pgsql-performance |
Hello,
I'm working on setting up replication with Slony, and will soon have a
slave that a lot of SELECT traffic will be sent to (over 500k/day).
The primary query we need to run is somewhat complex, but seems to
complete on average in well under a second.
However, every so often (less in 1 in 10,000 queries) we'll see the
query take 2 or 3 minutes.
It's not clear why this is happening-- perhaps there is something else
going on that is affecting this query.
I'm considering the use of "statement_timeout" to limit the time of
this particular query, to suppress the rare "run away", and avoid tying
up the processor for that additional time.
I think it may be better to give up, quit spending cycles on it right
then, and return an "oops, try again in a few minutes" message instead.
From the data we have, seems like it has a strong chance of working again.
Is anyone else using "statement_timeout" as part of an overall
performance plan?
Mark
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера