| From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
|---|---|
| To: | Christopher Browne <cbbrowne(at)acm(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: *sigh* |
| Date: | 2003-12-03 08:29:08 |
| Message-ID: | 3FCD9ED4.1000108@paradise.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
How about:
Implement a function "estimated_count" that can be used instead of
"count". It could use something like the algorithm in
src/backend/commands/analyze.c to get a reasonably accurate psuedo count
quickly.
The advantage of this approach is that "count" still means (exact)count
(for your xact snapshot anyway). Then the situation becomes:
Want a fast count? - use estimated_count(*)
Want an exact count - use count(*)
regards
Mark
Christopher Browne wrote:
>For a small table, it will be cheaper to walk through and calculate
>count(*) directly from the tuples themselves.
>
>The situation where it may be worthwhile to do this is a table which
>is rather large (thus count(*) is expensive) where there is some
>special reason to truly care how many rows there are in the table.
>For _most_ tables, it seems unlikely that this will be true. For
>_most_ tables, it is absolutely not worth the cost of tracking the
>information.
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2003-12-03 09:03:30 | Re: Transaction Question |
| Previous Message | John Sidney-Woollett | 2003-12-03 08:08:49 | Transaction Question |