Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Wed, 26 Dec 2007, Guillaume Smet wrote:
> >> beta RPMs are by default compiled with --enable-debug and
> >> --enable-cassert which doesn't help them to fly fast...
>
> > Got that right. Last time I was going crazy after running pgben
On Dec 25, 2007 7:06 PM, Guillaume Smet <[EMAIL PROTECTED]> wrote:
> While monitoring the server with vmstat, I can't see any real reason
> why it's slower. When shared_buffers has a higher value, I/O are
> lower, context switches too and finally performances. The CPU usage is
> quite similar (~50-
On Dec 27, 2007 7:54 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I concur with Greg Stark's earlier comment that this is all
> overreaction. Let's just fix the misleading comment in the
> documentation and leave it at that.
IMHO, we should also have a special tag for all the binaries
distributed wi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Perhaps make them emit a WARNING at server start or something.
I concur with Greg Stark's earlier comment that this is all
overreaction. Let's just fix the misleading comment in the
documentation and leave it at that.
regards,
Tom Lane escribió:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > ... I didn't think this was a big problem because I
> > thought it was limited to developers who shot their own foot, but if there
> > are packagers turning this on to improve beta feedback it deserves some
> > wider mention.
>
>
"Greg Smith" <[EMAIL PROTECTED]> writes:
> The worst time people can run into a performance
> regression is when they're running a popular benchmarking tool.
Hm, perhaps pg_bench should do a "show debug_assertions" and print a warning
if the answer isn't "off". We could encourage other benchmar
Greg Smith <[EMAIL PROTECTED]> writes:
> ... I didn't think this was a big problem because I
> thought it was limited to developers who shot their own foot, but if there
> are packagers turning this on to improve beta feedback it deserves some
> wider mention.
Yeah, binary packages that are bu
On Thu, 27 Dec 2007, Gregory Stark wrote:
Fwiw I think you're all getting a bit caught up in this one context.
I lost a day once over this problem. Guillaume lost at least that much.
Sounds like Magnus and Dave got a good sized dose as well. Seems like
something worth warning people about
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>
>> Currently the docs say that --enable-cassert
>>
>> Enables assertion checks in the server, which test for
>> many cannot happen conditions. This is invaluable for
>> code development purposes, but t
Tom Lane escribió:
> Currently the docs say that --enable-cassert
>
> Enables assertion checks in the server, which test for
> many cannot happen conditions. This is invaluable for
> code development purposes, but the tests slow things down a little.
>
> Maybe we ough
On Thu, Dec 27, 2007 at 01:10:29AM -0500, Tom Lane wrote:
> Greg Smith <[EMAIL PROTECTED]> writes:
> > On Wed, 26 Dec 2007, Guillaume Smet wrote:
> >> beta RPMs are by default compiled with --enable-debug and
> >> --enable-cassert which doesn't help them to fly fast...
>
> > Got that right. Last
On Dec 27, 2007 7:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Enables assertion checks in the server, which test for
> many cannot happen conditions. This is invaluable for
> code development purposes, but the tests slow things down a little.
>
> Maybe we ought to put t
Greg Smith <[EMAIL PROTECTED]> writes:
> On Wed, 26 Dec 2007, Guillaume Smet wrote:
>> beta RPMs are by default compiled with --enable-debug and
>> --enable-cassert which doesn't help them to fly fast...
> Got that right. Last time I was going crazy after running pgbench with
> those options and
Hi,
On Wed, 2007-12-26 at 18:35 -0500, Greg Smith wrote:
> Probably need to put a disclaimer about that fact *somewhere*.
We mention about that in README.rpm-dist file, but I think we should
mention about that at a more visible place.
Regards,
--
Devrim GÜNDÜZ , RHCE
PostgreSQL Replication, Co
On Wed, 26 Dec 2007, Guillaume Smet wrote:
beta RPMs are by default compiled with --enable-debug and
--enable-cassert which doesn't help them to fly fast...
Got that right. Last time I was going crazy after running pgbench with
those options and not having realized what I changed, I was gett
On Dec 26, 2007 10:52 PM, Guillaume Smet <[EMAIL PROTECTED]> wrote:
> Let's go with 8.2.5 on the same server (-s 100 / 16 clients / 50k
> transactions per client / only read using -S option):
> 64MB: 33814 tps
> 512MB: 35833 tps
> 1024MB: 36986 tps
> It's more consistent with what I expected.
I ha
On Dec 26, 2007 7:23 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> Ah, now this is really interesting, as it rules out all the write
> components and should be easy to replicate even on a smaller server. As
> you've already dumped a bunch of time into this the only other thing I
> would suggest chec
On Wed, 26 Dec 2007, Guillaume Smet wrote:
It's not checkpointing either as using pgbench-tools, I can see that
tps and latency are quite stable during the entire run. Btw, thanks
Greg for these nice tools.
I stole the graph idea from Mark Wong's DBT2 code and one of these days
I'll credit hi
On Dec 26, 2007 4:41 PM, Guillaume Smet <[EMAIL PROTECTED]> wrote:
> Then I decided to perform read-only tests using -S option (pgbench -S
> -s 100 -c 16 -t 3 -U postgres bench). And still the same
> behaviour:
> shared_buffers=64MB : 20k tps
> shared_buffers=1024MB : 8k tps
Some more informat
Hello
I tested it and it is true. In my configuration 1GRam, Fedora 8, is
PostgreSQL most fast with 32M shared buffers :(. Diff is about 5% to
256M
Regards
Pavel Stehule
On 26/12/2007, Guillaume Smet <[EMAIL PROTECTED]> wrote:
> On Dec 26, 2007 12:21 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
On Dec 26, 2007 12:21 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> bgwriter_lru_maxpages = 0
>
> So we can see if the bgwriter has any hand in this?
It doesn't change the behaviour I have.
It's not checkpointing either as using pgbench-tools, I can see that
tps and latency are quite stable during
On Dec 26, 2007 12:21 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> Can you try with
>
> bgwriter_lru_maxpages = 0
>
> So we can see if the bgwriter has any hand in this?
I will. I'm currently running tests with less concurrent clients (16)
with exactly the same results:
64M 4213.314902
256M 4012.7
On Dec 26, 2007 12:06 PM, Cédric Villemain <[EMAIL PROTECTED]> wrote:
> Which kernel do you have ?
Kernel of the distro. So a RH flavoured 2.6.18.
--
Guillaume
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desi
On Wed, 2007-12-26 at 01:06 +0100, Guillaume Smet wrote:
> I lowered the number of concurrent clients to 50 because 100 is quite
> high and I obtain the same sort of results:
> shared_buffers=32MB: 1869 tps
> shared_buffers=64MB: 1844 tps
> shared_buffers=512MB: 1676 tps
> shared_buffers=1024MB: 1
Guillaume Smet a écrit :
Hi all,
I'm currently benchmarking the new PostgreSQL server of one of our
customers with PostgreSQL 8.3 beta4. I have more or less the same
configuration Stefan tested in his blog [1]:
- Dell 2900 with two brand new X5365 processors (quad core 3.0 GHz),
16 GB of memory
25 matches
Mail list logo
