From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Win2K Questions |
Date: | 2002-11-10 05:13:51 |
Message-ID: | 6866.1036905231@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Richard Huxton <dev(at)archonet(dot)com> writes:
> On Friday 08 Nov 2002 5:21 pm, Bruce Momjian wrote:
>> The problem with optimizing COUNT() is that different backends have
>> different tuple views, meaning the count from one backend could be
>> different than from another backend. I can't see how to optimize that.
> The only way I could model it when I thought about it some time ago was as
> though you had a separate table "pg_table_counts" with columns (tableoid,
> count) - every insert/delete would also update this table.
The problem with that is that it would create a serialization
bottleneck: if transaction A has done an insert into table X, then every
other transaction B that wants to insert or delete in X has to wait for
A to commit or abort before B can update X's row in pg_table_counts.
That is exactly the scenario that MVCC was designed to avoid.
What it comes down to is that you can optimize "select count(*) from
foo" at the expense of slowing down *every* kind of database-update
operation. We don't think that's a win.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-11-10 05:27:53 | Re: [HACKERS] PostgreSQL JDBC and sub-select |
Previous Message | elein | 2002-11-09 22:19:36 | Re: Recursive call indicator/counter |