From: | Satoshi Nagayasu <nagayasus(at)nttdata(dot)co(dot)jp> |
---|---|
To: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
Cc: | Satoshi Nagayasu <nagayasus(at)nttdata(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: lock timeout patch |
Date: | 2004-06-29 00:25:27 |
Message-ID: | 40E0B6F7.30104@noanet06.noanet.nttdata.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)nttdata(dot)co(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Wu | 2004-06-29 02:21:10 | working on support triggers on columns |
Previous Message | Satoshi Nagayasu | 2004-06-28 23:34:14 | Re: lock timeout patch |