Turns out the 40% was due to a configuration problem with my application. I'm
now getting the same performance with community edition.
It appears that I'm now CPU bound. My CPU's are all pegged.
-- Les Walker
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql
Yes. I didn't know the proper vernacular :-)
It is very likely that the default settings are different. I'm looking at that
right now.
-- Les Walker
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Thomas Kelle
Walker, James Les wrote on 01.05.2012 16:44:
I installed the enterprisedb distribution and immediately saw a 400%
performance increase.
What exactly is "the enterprisedb distribution"?
Are you talking about the the Advanced Server?
I would be very surprised if the code base would differ so mu
On Tue, May 1, 2012 at 9:44 AM, Walker, James Les wrote:
> I installed the enterprisedb distribution and immediately saw a 400%
> performance increase. Turning off fsck made it an order of magnitude better.
> I'm now peaking at over 400 commits per second. Does that sound right?
yeah -- well it
Hi Tom,
Thanks for your reply.
> What PG version are we talking about here?
For development I use 9.1.3, on the production server is 8.4.7 -
happens with both cases.
> That doesn't sound like a tremendously good idea to me.
Could you elaborate on the downsides of this approach a bit?
> But with
I installed the enterprisedb distribution and immediately saw a 400%
performance increase. Turning off fsck made it an order of magnitude better.
I'm now peaking at over 400 commits per second. Does that sound right?
If I understand what you're saying, then to sustain this high rate I'm going to
Clemens Eisserer writes:
> Quite often Hibernate ends up generating queries with a lot of joins
> which usually works well, except for queries which load some
> additional data based on a previous query (SUBSELECT collections),
> which look like:
> select . from table1 ... left outer join tab
Hi,
I am using postgresql as database for a hibernate based java oltp
project and as in previous projects am totally impressed by
postgresql's robustness, performance and feature-richness. Thanks for
this excellent piece of software.
Quite often Hibernate ends up generating queries with a lot of
On Tue, May 1, 2012 at 8:14 AM, Walker, James Les wrote:
> SSD is OCZ-VERTEX3 MI. Controller is LSI SAS2 2008 Falcon. I'm working on
> installing EDB. Then I can give you some I/O numbers.
It looks like the ssd doesn't have a nv cache and the raid card is a
simple sas hba (which likely isn't doi
On 5/1/2012 8:06 AM, Merlin Moncure wrote:
On Tue, May 1, 2012 at 7:51 AM, Walker, James Les wrote:
Exactly, if turning off fsync gives me 100 commits/sec then I know where my
bottleneck is and I can attack it. Keep in mind though that I already turned
off synchronous commit -- *really* dange
SSD is OCZ-VERTEX3 MI. Controller is LSI SAS2 2008 Falcon. I'm working on
installing EDB. Then I can give you some I/O numbers.
-- Les
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Tuesday, May 01, 2012 9:07 AM
To: Walker, James Les
Cc: Thomas Kellerer; pgsql
On Tue, May 1, 2012 at 7:51 AM, Walker, James Les wrote:
> Exactly, if turning off fsync gives me 100 commits/sec then I know where my
> bottleneck is and I can attack it. Keep in mind though that I already turned
> off synchronous commit -- *really* dangerous -- and it didn't have any effect.
Exactly, if turning off fsync gives me 100 commits/sec then I know where my
bottleneck is and I can attack it. Keep in mind though that I already turned
off synchronous commit -- *really* dangerous -- and it didn't have any effect.
-- Les
-Original Message-
From: pgsql-performance-ow...
13 matches
Mail list logo
