| From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
|---|---|
| To: | David Wall <d(dot)wall(at)computer(dot)org> |
| Cc: | pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: SELECT COUNT(*) does a scan? |
| Date: | 2005-09-08 15:40:46 |
| Message-ID: | 43205B7E.3080505@opencloud.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
David Wall wrote:
> When I do an EXPLAIN SELECT COUNT(*) FROM tablename, I noted that it
> does a table scan. I thought PG had some sort of table stat that kept
> track of the current number of rows in a table, but that doesn't appear
> to always be the case.
It's not the case, and this is a FAQ -- search archives.postgresql.org
for more details (the short version is that maintaining a row count
doesn't work well with MVCC).
> It seems that right after a VACUUM ANALYZE, that command is very fast (on a table with 100,000+ rows), but it can also get quite slow, as if a table scan is taking place.
> Does this make sense? Is there an algorithm that says to use the stats from analyze only until sufficient updates/inserts/deletes have taken place to make them "out of date"?
Most likely a VACUUM ANALYZE is just pulling the whole table into cache,
so there is less disk I/O needed to do the scan.
-O
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Cramer | 2005-09-08 18:15:21 | Re: SELECT COUNT(*) does a scan? |
| Previous Message | Richard Huxton | 2005-09-08 15:27:03 | Re: BUG #1864: Strange behavoir of batches |