Re: SELECT constant; takes 15x longer on 9.0?

Merlin Moncure wrote:
> On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Greg has the right idea: show debug_assertions.
>>
>
> why not the entire set of configure options?
>

Given that the standard way to find those is pg_config, there's a couple
of reasons why not to prefer that, on top of those Tom already mentioned:

1) pg_config isn't in the standard PostgreSQL package set in some
distributions (it's sometimes in the -devel package), so it may not be
available; debug_assertions is always there if you have psql. For my
goals, which include benchmarking scripts I often distribute to other
people, that matters.

2) It's easy to get pg_config output from your client that doesn't
actually match the running server, particularly when developing. That's
been the source of more than one of the times I was running a debug
build on the server but didn't notice it, and therefore would have
produced worthless performance numbers. Given that the main slowdowns
from having assertions turned on are server side, whether or not the
local client running things like psql have them turned on or not doesn't
worry me as much.

3) It's a little easier to check the value of "show" in a script to
confirm you're not running a bad build than to parse the output from
pg_config. Here's the recipe I use for shell scripts:

#!/bin/sh
DEBUG=`psql -At -c "show debug_assertions"`
if [ "$DEBUG" = "on" ] ; then
echo "Debug build - aborting performance test"
exit 1
fi

Pushing this data into something like version() would solve the first
two items above, while making the issue of how to parse the results in a
test client even harder, given there's already too much junk in one big
string there. You couldn't make the above check much simpler, which
makes it hard to justify any alternative approach to grab this data.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us