Re: PostgreSQL Gotchas --- count()

On Informix however it is blindingly fast, and can also be instantly conjured with the dbaccess tool (Info/Table/Status). They might be stashing this count somewhere, but it is not available when the table is locked, as during a load. However they do it, performance does not seem to suffer, and having this rapidly available is certainly nice. Especially when people are used to it.

Greg Williamson
DBA
GlobeXplorer LLC

-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org on behalf of Jeffrey Melloy
Sent: Thu 10/6/2005 3:47 PM
To: Neil Conway
Cc: Aly S.P Dharshi; pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] PostgreSQL Gotchas
Neil Conway wrote:

>
>"COUNT(*) very slow": this is a known issue -- see the -hackers archives
>for many prior discussions. MVCC makes this hard to solve effectively
>(whether applications should actually be using COUNT(*) on large tables
>with no WHERE clause is another matter...)
>
>-Neil
>
>
And it's not like a count(*) on an Oracle database of any decently-sized
dataset is blazing fast, or even in blazing's ballpark.

The only thing I could see actually being an issue is the random() one
and add missing from. The rest are trivial. The random() thing is
interesting, esoteric, and probably has never been a problem in a real
situation. (Or has exactly once, when he wrote that gotcha)

Jeff

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

!DSPAM:4345aeea115747915089936!