On 1/28/09, Phoenix Kiula <phoenix.kiula@gmail.com> wrote:
> [Ppsted similar note to PG General but I suppose it's more appropriate
> in this list. Apologies for cross-posting.]
>
> Hi. Further to my bafflement with the "count(*)" queries as described
> in this thread:
>
> http://archives.postgresql.org/pgsql-general/2009-01/msg00804.php
>
> It seems that whenever this question has come up, Postgresql comes up
> very short in terms of "count(*)" functions.
>
> The performance is always slow, because of the planner's need to guess
> and such. I don't fully understand how the statistics work (and the
> explanation on the PG website is way too geeky) but he columns I work
> with already have a stat level of 100. Not helping at all.
Your issue is not statistics/planner. postgres just can't apply the
special case optimization that some other database do because of the
locking model.
all planner's 'guess'. the main goal of statistics is to make the
guess better educated.
> We are now considering a web based logging functionality for users of
> our website. This means the table could be heavily INSERTed into. We
> get about 10 million hits a day, and I'm guessing that we will have to
> keep this data around for a while.
10m hits/day = 115 hits/sec. This is no problem for even workstation
box assuming your disks can handle the syncs. however, with extreme
insert heavy loads it helps alot to look at partitioning/rotation to
ease the pain of big deletes.
merlin