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