SELECT constant; takes 15x longer on 9.0?
in [PgSql]
|
Prev: Remaining Streaming Replication Open Items
Next: pgsql: Check compulsory parameters in recovery.conf in standby_mode, per
From: Tom Lane on 6 Apr 2010 17:40 Merlin Moncure <mmoncure(a)gmail.com> writes: > On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Greg has the right idea: show debug_assertions. > why not the entire set of configure options? We've discussed that before. pg_config already provides that info, and there was some concern about security risks of exposing it inside the database. (In particular, we currently go to some lengths to not expose any file path information to non-superusers.) If there's a reason to expose *individual* configuration options that aren't already easily checkable, we could discuss that. I would be against sticking it into version() output in any case. That function's already overloaded beyond any sane interpretation of its purpose, to the point where it's difficult to make use of the output programmatically. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Smith on 6 Apr 2010 23:33 Merlin Moncure wrote: > On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <tgl(a)sss.pgh.pa.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(a)2ndQuadrant.com www.2ndQuadrant.us
From: Pavel Stehule on 7 Apr 2010 02:02
2010/4/7 Greg Smith <greg(a)2ndquadrant.com>: > Merlin Moncure wrote: > > On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <tgl(a)sss.pgh.pa.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(a)2ndQuadrant.com www.2ndQuadrant.us > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |