But there are ways that we could optimize count(*) queries for specific
circumstances right? Obviously this isn't trivial, but I think it would
be nice if we could maintain a number of rows count that could be used
when performing a count(*) on the whole table (no where clause).
I don't know if the overhead of keeping track of that number is worth
the benefits - but I know that querying for the number of rows in a
table is a common need and other RDBMSs do optimize for that special
case.
On Tue, 23 Jan 2007 12:53:43 -0600, "Bruno Wolff III" <bruno@wolff.to>
said:
> On Tue, Jan 23, 2007 at 10:12:13 -0500,
> Brandon Aiken <BAiken@winemantech.com> wrote:
> > Out of curiosity, has the COUNT(*) with no WHERE clause slowness been
> > fixed in 8.x? Or is it still an issue of "there's no solution that
> > won't harm aggregates with WHERE clauses"?
>
> Probably not in the sense that you mean.
>
> The underlying problem is that in MVCC there is no single global answer
> to the question and the pain of maintaining the mutliple answers
> outweighs
> the cost of doing so in normal usage.
>
> People that need to run count(*) queries a lot may want to make a
> different
> trade off and some ways of maintaining counts are covered in the
> archives.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq