Re: lock timeout patch
От | Satoshi Nagayasu |
---|---|
Тема | Re: lock timeout patch |
Дата | |
Msg-id | 40E0B6F7.30104@noanet06.noanet.nttdata.co.jp обсуждение исходный текст |
Ответ на | Re: lock timeout patch (Dennis Bjorklund <db@zigo.dhs.org>) |
Ответы |
Re: lock timeout patch
|
Список | pgsql-hackers |
Dennis Bjorklund wrote: >>If I set statement_timeout to 1000 to detect a lock timeout, >>I can't run a query which takes over 1 sec. >> >>If a lock wait is occured, I want to detect it immediately, >>but I still want to run a long-running query. > > > Why is it important what it is that makes your query not return as fast as > you expect? Maybe it's locking, maybe the computer is swapping, maybe it's > just lack of IO to that disk that holds the table, maybe it does a big > sort and have too little sort_mem to do it fast, ... > > What makes locking special? Processing slow-down is just a hardware/software sizing issue. Of course we need to fix it when a problem is occured, but I think it's a different kind of problem. In large databases, such as DSS(decision support system), some queries takes one or more minutes. I think it's okey. But I don't want to wait one or more minutes just for a lock. I need to return a message to the user "retry later." or something like that. It depends on various applications. So I think detecting a lock waiting is important. -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp>
В списке pgsql-hackers по дате отправления: