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

2010/4/7 Greg Smith <greg(at)2ndquadrant(dot)com>:
> 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.
>

good idea. Can do it to 9.0? It has zero impact on behave and can help
to protect us against same bug.

I plan one night test fest on begin of may in Prague, and wouldn't do
same mistake :). But it is really import feature - maybe can signaled
in promt in future.

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