Hello.
I have a server with 4GB of RAM and PostgreSQL 9.0.3 on Centos 5. I'm using
pgbench and pgbench-tools to measure performance, using two pgbench-tools
queries: select and tpc-b.
With default settings of postgresql.conf and select query, I get the
following results:
Scale: 1, 10, 100, 1000.
Javier,
There has been much discussion of this.
Generally - and though it's a bit counter-intuitive - wholesale increase in
PostgreSQL's shared buffer won't give you the outcomes you might expect. In
short, once there's enough, there's enough. Workmem is another option which
behaves along
Javier Reyes writes:
> I have a server with 4GB of RAM and PostgreSQL 9.0.3 on Centos 5. I'm using
> pgbench and pgbench-tools to measure performance, using two pgbench-tools
> queries: select and tpc-b.
> With default settings of postgresql.conf and select query, I get the
> following results:
On 04/27/2011 03:35 PM, Mark Stosberg wrote:
In particular, I wanted to check whether the UPDATE statement would
alter all the rows automatically, or if the underlying trigger would
cause all the rows processed a row at a time.
It appears from my test that the result of the UPDATE was going to
a
On 04/22/2011 08:23 PM, Brian Fehrle wrote:
So long story short, if a cluster has zero activity, and
archive_timeout is not set to 0, when it reaches that timeout should
it generate a file, or just skip because it would be 100% empty?
You're right about what you've seen here, there is some log
