On Tue, Jan 23, 2007 at 14:15:23 -0500, Jeremy Haile <[EMAIL PROTECTED]> wrote: > 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).
People can already do that. How to do it right (to avoid update contention) is even described in the mailing list archives. There just isn't a nice contrib or pgfoundry project to wrap it up for them. Of course if there was people might install the project even though there was a net loss in performance for them. > 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. That is debatable. Certainly a lot of people run adhoc unconstrained count(*) queries. Whether they normally need exact counts or whether the number of such queries is large enough compared to other queries being done to be considered common is another matter. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
