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@xxxxxxxx> said: > On Tue, Jan 23, 2007 at 10:12:13 -0500, > Brandon Aiken <BAiken@xxxxxxxxxxxxxxx> 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
