Re: Implementing cost limit/delays for insert/delete/update/select
В списке pgsql-hackers по дате отправления:
| От | Simon Riggs |
|---|---|
| Тема | Re: Implementing cost limit/delays for insert/delete/update/select |
| Дата | |
| Msg-id | 1219748617.5343.1310.camel@ebony.2ndQuadrant обсуждение исходный текст |
| Ответ на | Implementing cost limit/delays for insert/delete/update/select (Peter Schuller <peter.schuller@infidyne.com>) |
| Список | pgsql-hackers |
On Mon, 2008-08-25 at 22:39 +0200, Peter Schuller wrote: > Does this sound vaguely sensible? Is there an obvious show-stopper I > am missing? This was a well structured proposal. The main problem is where you put the delay_point() calls. If you put them at the top of the executor then you will get a delay proportional to the number of rows retrieved. For many queries, such as count(*) this might be just one row, yet have run for hours. There's no point having a priority scheme if it doesn't apply to all queries equally. If you put them at each call of each node then you will get an unacceptable overhead as Tom suggests. Not sure what to suggest, if anything, apart from just writing your own delay() function and using it in your query. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера