Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Дата
Msg-id 4A08B5E4.4050009@agliodbs.com
обсуждение исходный текст
Ответ на Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Hans-Juergen Schoenig <postgres@cybertec.at>)
Список pgsql-hackers
On 5/11/09 4:25 PM, Tom Lane wrote:
> Josh Berkus<josh@agliodbs.com>  writes:
>> I can see Zoltan's argument: for web applications, it's important to
>> keep the *total* wait time under 50 seconds for most users (default
>> browser timeout for most is 60 seconds).
>
> And why is that only about lock wait time and not about total execution
> time?  I still think statement_timeout covers the need, or at least is
> close enough that it isn't justified to make lock_timeout act like that
> (thus making it not serve the other class of requirement).

That was one of the reasons it's "completely and totally unworkable", as 
I mentioned, if you read the next sentence.

The only real answer to the response time issue is to measure total 
response time in the middleware.

-- 
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Show method of index
Следующее
От: Tom Lane
Дата:
Сообщение: Re: DROP TABLE vs inheritance