On Wed, Sep 19, 2012 at 5:34 AM, mal.oracledba wrote:
> Running hammer ora TPC-C type load. Under 20 user load (no key and think)
> getting approx 180,000 TPM - which is about half of what I get with another
> database vendor.
>
> tracing the process (strace -r) I get outtput like that below - a l
On Fri, Sep 21, 2012 at 7:46 AM, Jon Leighton wrote:
> So my question is: is this a worthwhile optimisation to make? In
> particular, I am wondering whether empty transactions increase the work
> the database has to do when there are several other connections open?
> I.e. does it cause contention?
On Sun, Sep 16, 2012 at 12:48 AM, Umesh Kirdat wrote:
> The issue we have noticed is the 9.0.4 (64 bit) version of PostgreSQL has
> slower performance as compared to 8.2.2 (32 bit) version on an identical
> hardware.
First of all, that's comparing apples and oranges. Compare the same
version in 3
Hello!
I'm one of the developers of the Ruby on Rails web framework.
In some situations, the framework generates an empty transaction block.
I.e. we sent a BEGIN and then later a COMMIT, with no other queries in
the middle.
We currently can't avoid doing this, because a user *may* send queries
i
Using postgreSQL 9.2 with the following settings:
max_connections = 1000 # (change requires restart)
shared_buffers = 65536MB# min 128kB
work_mem = 16MB # min 64kB
effective_io_concurrency = 48 # 1-1000; 0 disables prefetching
wal_
On 14/09/2012 22:19, Sébastien Lorion wrote:
> I am not able to set wal_sync_method to anything but fsync on FreeBSD 9.0
> for a DB created on ZFS (I have not tested on UFS). Is that expected ? Has
> it anything to do with running on EC2 ?
Can you explain what prevents you for setting the wal_sync
Hello All,
We are migrating our product from 32 bit CentOS version 5.0 (kernel 2.6.18) to
64 bit CentOS version 6.0 (kernel 2.6.32)
So we decided to upgrade the PostgreSQL version from 8.2.2 to 9.0.4
We are compiling the PostgreSQL source on our build machine to create an RPM
before using it
