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

Merlin Moncure wrote: <blockquote cite="mid:w2vb42b73151004061313ofb82c383za0cd2a0966c17903@mail.gmail.com"
type="cite"><prewrap="">On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <a class="moz-txt-link-rfc2396E"
href="mailto:tgl@sss.pgh.pa.us"><tgl@sss.pgh.pa.us></a>wrote: </pre><blockquote type="cite"><pre wrap="">Greg has
theright idea: show debug_assertions.   </pre></blockquote><pre wrap="">
 
why not the entire set of configure options? </pre></blockquote><br /> 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:<br /><br /> 1)
pg_configisn't in the standard PostgreSQL package set in some distributions (it's sometimes in the -devel package), so
itmay not be available; debug_assertions is always there if you have psql.  For my goals, which include benchmarking
scriptsI often distribute to other people, that matters.<br /><br /> 2) It's easy to get pg_config output from your
clientthat doesn't actually match the running server, particularly when developing.  That's been the source of more
thanone of the times I was running a debug build on the server but didn't notice it, and therefore would have produced
worthlessperformance numbers.  Given that the main slowdowns from having assertions turned on are server side, whether
ornot the local client running things like psql have them turned on or not doesn't worry me as much.<br /><br /> 3)
It'sa little easier to check the value of "show" in a script to confirm you're not running a bad build than to parse
theoutput from pg_config.  Here's the recipe I use for shell scripts:<br /><br /> #!/bin/sh<br /> DEBUG=`psql -At -c
"showdebug_assertions"`<br /> if [ "$DEBUG" = "on" ] ; then <br />   echo "Debug build - aborting performance test"<br
/>  exit 1<br /> fi<br /><br /> Pushing this data into something like version() would solve the first two items above,
whilemaking the issue of how to parse the results in a test client even harder, given there's already too much junk in
onebig string there.  You couldn't make the above check much simpler, which makes it hard to justify any alternative
approachto grab this data.<br /><br /><pre class="moz-signature" cols="72">-- 
 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
<a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a>   <a
class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>
 
</pre>