| From: | Randolf Richardson <rr(at)8x(dot)ca> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: *sigh* |
| Date: | 2003-12-03 05:20:35 |
| Message-ID: | Xns9445D70A46474rr8xca@200.46.204.72 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> The count(*) information can be revisioned too, am I wrong ? I'm able
>> to create a trigger that store the count(*) information in a special
>> table, why not implement the same in a way "builded in" ?
>
> Then every insert or delete would have to lock that count. Nobody else
> would be able to insert or delete any records until you either commit or
> roll back.
>
> That would lead to much lower concurrency, much more contention for
> locks, and tons of deadlocks.
What about queueing all these updates for a separate low-priority
thread? The thread would be the only one with access to update this field.
--
Randolf Richardson - rr(at)8x(dot)ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Natoli | 2003-12-03 05:30:40 | Re: [HACKERS] fork/exec problem: DynaHashCxt |
| Previous Message | Tom Lane | 2003-12-03 05:01:53 | Re: [HACKERS] fork/exec problem: DynaHashCxt |