On 10/10/2010 11:02 AM, Neil Whelchel wrote:
On Saturday 09 October 2010 18:47:34 Scott Marlowe wrote:
On Sat, Oct 9, 2010 at 5:26 PM, 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 row
On 10/10/2010 2:43 AM, Craig Ringer wrote:
Some of the other flavours of non-SQL databases, both those that've been
around forever (PICK/UniVerse/etc, Berkeley DB, Cache, etc) and those
that're new and fashionable Cassandra, CouchDB, etc, provide some ACID
properties anyway. If you don't need/w
On 10/10/2010 5:35 AM, Mladen Gogala wrote:
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
On Sat, Oct 9, 2010 at 7:44 PM, Mladen Gogala wrote:
> 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 they have already made t
On Saturday 09 October 2010 18:47:34 Scott Marlowe wrote:
> On Sat, Oct 9, 2010 at 5:26 PM, 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
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 somet
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 something similar and
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 wor
On Sat, Oct 9, 2010 at 5:26 PM, 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 ke
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 situation
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
* 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 gathe
12 matches
Mail list logo
