| From: | "David F(dot) Skoll" <dfs(at)roaringpenguin(dot)com> |
|---|---|
| To: | Sam Barnett-Cormack <s(dot)barnett-cormack(at)lancaster(dot)ac(dot)uk> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Row locking during UPDATE |
| Date: | 2003-09-04 17:10:34 |
| Message-ID: | Pine.LNX.4.55.0309041308250.3434@shishi.roaringpenguin.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Thu, 4 Sep 2003, Sam Barnett-Cormack wrote:
> It might be worth racking your brains to think of other ways. Query
> timeouts?
Either way, if the back-end is waiting on a semaphore, will it time
out the query and terminate? The problem is lots of waiting back-end
processes.
> why not make it store a new record for each instance, and have a cronjob
> each day update the statistics from that. It will be more efficient,
> overall. It can be done hourly, even.
I posted a compromise solution: A "low-contention" table that reduces
the likelihood of contention. Adding a new record could result in pretty
large tables that need to be summarised. I'll play around with the
low-contention table first.
Regards,
David.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-09-04 17:20:50 | Re: Log error at server startup |
| Previous Message | Stephan Szabo | 2003-09-04 15:50:52 | Re: LOCK has IGNORED on trigger. |