| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Neil Conway <neilc(at)samurai(dot)com>, Christopher Browne <cbbrowne(at)acm(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Seqscan in MAX(index_column) |
| Date: | 2003-09-05 03:08:17 |
| Message-ID: | 25643.1062731297@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Neil Conway wrote:
>> In general, I don't think this is worth doing.
> It is possible it isn't worth doing. Can the INSERT/DELETE
> incrementing/decrementing the cached count work reliabily?
I don't even see how the notion of a single cached value makes
theoretical sense, when in principle every transaction may have
a different idea of the correct answer.
You could doubtless maintain a fairly good approximate total this
way, and that would be highly useful for some applications ...
but it isn't COUNT(*).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-09-05 03:25:10 | Re: Seqscan in MAX(index_column) |
| Previous Message | Matthew T. O'Connor | 2003-09-05 02:57:50 | Re: Another small bug (pg_autovacuum) |