"Greg Smith" <gsmith@gregsmith.com> 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 benchmark software to do
something similar.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane escribió:
> Greg Smith <gsmith@gregsmith.com> 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 built with --enable-cassert perhaps need
> to be labeled as "not intended for benchmarking" or some such.

Perhaps make them emit a WARNING at server start or something.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Alvaro Herrera <alvherre@commandprompt.com> 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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Dec 27, 2007 7:54 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 with these options on the official website (RPM or not).
If the RPM packages' version has been tagged .debug or something like
that, it would have been the first thing I checked.

I like Gregory's idea to add a warning in pgbench. I usually run a few
pgbench tests to check there is no obvious problem even if I use
another more complicated benchmark afterwards. I don't know if that's
what other people do, though.

--
Guillaume

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Dec 25, 2007 7:06 PM, Guillaume Smet <guillaume.smet@gmail.com> 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-60%). I/O doesn't limit the performances AFAICS.

Can you confirm that i/o is lower according to iostat? One
possibility is that you are on the cusp of where your server's memory
covers the database and the higher buffers results in lower memory
efficiency.

If raising shared buffers is getting you more page faults to disk,
this would explain the lower figures regardless of the # of syscalls.
If your iowait is zero though the test is cpu bound and this
distinction is moot.

merlin

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane wrote:
> Greg Smith <gsmith@gregsmith.com> 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 not having realized what I changed, I was getting a 50%
> > slowdown on results that way compared to without the debugging stuff.
> > Didn't realize it scaled with shared_buffers though.
>
> See AtEOXact_Buffers(). There are probably any number of other
> interesting scaling behaviors --- in my tests, AllocSetCheck() is
> normally a major cycle-eater if --enable-cassert is set, and that costs
> time proportional to the number of memory chunks allocated by the query.
>
> Currently the docs say that --enable-cassert
>
> Enables <firstterm>assertion</> checks in the server, which test for
> many <quote>cannot happen</> conditions. This is invaluable for
> code development purposes, but the tests slow things down a little.
>
> Maybe we ought to put that more strongly --- s/a little/significantly/,
> perhaps?

Docs updated with attached patch, backpatched to 8.3.X.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://mail.postgresql.org/mj/mj_www...ql-performance