Kevin Grittner wrote:
> After running a series of tests with --enable-cassert to confirm
> that nothing squawked, I disabled that before doing any
> performance testing. Going from memory, I used --enable-debug
> --with-libxml and --prefix. I didn't explicitly use or disable any
> compiler optimizations.
>
> Possibly relevant is that I was using Greg Smith's peg tool (as best
> I could):
>
> http://github.com/gregs1104/peg/
>
> I'm not aware of it doing anything to the compile options, but I
> didn't look for that, either.
Now that you ask, of course I just spotted a bug in there such that the
documented behavior for the PGDEBUG feature doesn't actually work. If
you were using that to turn off asserts, that may not have worked as
expected. Don't know what you did there exactly. Fix now pushed to the
repo.
I general, when doing performance testing, now matter how careful I've
been I try to do a:
show debug_assertions;
To confirm I'm not running with those on.
Andres, are using any optimization flags when you're testing?
Would have preferred that the first mention of my new project didn't
involve a bug report, but that's software I guess. For everyone here
who's not on the reviewers mailing list: peg is a scripting tool I've
put together recently that makes it easier to setup the environment
(source code, binaries, database) for testing PostgreSQL in a
development content. It takes care of grabbing the latest source,
building, starting the database, all that boring stuff. I tried to make
it automate the most tedious parts of both development and patch
review. Documentation and the program itself are at the git repo Kevin
mentioned.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com
