* Greg Smith:
Given the size of your database, I'd advise you consider a migration
to a new version ASAP. 8.4 is a nice stable release at this point,
that's the one to consider moving to.
It also offers asynchronous commits, which might be a good tradeoff
here (especially if the data
I have a logical problem with asynchronous commit. The commit command
should instruct the database to make the outcome of the transaction
permanent. The application should wait to see whether the commit was
successful or not. Asynchronous behavior in the commit statement breaks
the ACID rules
I know that there haven been many discussions on the slowness of count(*) even
when an index is involved because the visibility of the rows has to be
checked. In the past I have seen many suggestions about using triggers and
tables to keep track of counts and while this works fine in a
On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel neil.whelc...@gmail.com wrote:
I know that there haven been many discussions on the slowness of count(*) even
when an index is involved because the visibility of the rows has to be
checked. In the past I have seen many suggestions about using
Neil Whelchel wrote:
I know that there haven been many discussions on the slowness of count(*) even
when an index is involved because the visibility of the rows has to be
checked. In the past I have seen many suggestions about using triggers and
tables to keep track of counts and while this
Joe Conway wrote:
On 10/09/2010 06:54 PM, Mladen Gogala wrote:
In another database, whose name I will not mention, there is a parameter
db_file_multiblock_read_count which specifies how many blocks will be
read by a single read when doing a full table scan. PostgreSQL is in
dire need of
On Saturday 09 October 2010 18:47:34 Scott Marlowe wrote:
On Sat, Oct 9, 2010 at 5:26 PM, Neil Whelchel neil.whelc...@gmail.com
wrote:
I know that there haven been many discussions on the slowness of count(*)
even when an index is involved because the visibility of the rows has to
be
On Sat, Oct 9, 2010 at 7:44 PM, Mladen Gogala mladen.gog...@vmsinfo.comwrote:
The architects of Postgres database would be well advised to operate under
the assumption that every production database has a competent DBA keeping an
eye on the database.
I'd actually go so far as to say that
