From: | Christoph Haller <ch(at)rodos(dot)fzk(dot)de> |
---|---|
To: | markir(at)paradise(dot)net(dot)nz (Mark Kirkwood) |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: *sigh* |
Date: | 2003-12-03 13:04:35 |
Message-ID: | 200312031204.NAA23410@rodos |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fairly good idea IMHO, especially considering Christopher's point
about the unlikeliness of needing an exact count anyway.
Regards, Christoph
>
> 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 | John Sidney-Woollett | 2003-12-03 13:34:30 | Re: Transaction Question |
Previous Message | Peter Eisentraut | 2003-12-03 12:52:35 | Re: Encoding problem with 7.4 |