| 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: | Christopher Browne <cbbrowne(at)libertyrms(dot)info>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: count(*) slow on large tables |
| Date: | 2003-10-04 17:51:38 |
| Message-ID: | 19444.1065289898@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> ... and it would give the wrong answers. Unless the cache is somehow
>> snapshot-aware, so that it can know which other transactions should be
>> included in your count.
> The cache is an ordinary table, with xid's on every row. I meant it
> would require no index/heap scans of the large table --- it would still
> require a scan of the "count" table.
Oh, that idea. Yeah, I think we had concluded it might work. You'd
better make the TODO item link to that discussion, because there's sure
been plenty of discussion of ideas that wouldn't work.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2003-10-04 18:09:14 | Re: hr translations |
| Previous Message | Robert Creager | 2003-10-04 17:51:28 | Re: pg_dump bug in 7.4 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-10-04 18:19:46 | Re: count(*) slow on large tables |
| Previous Message | Bruce Momjian | 2003-10-04 17:48:47 | Re: count(*) slow on large tables |