Tom Lane wrote:
> Nobody else seems to have commented, but maybe what this suggests is
> we need to be able to individually disable a few of the most expensive
> checks. I'm not sure what a reasonable API is for that ... not sure
> that I like the thought of a GUC for each one.
>
I'd really like to be able to do more long-running performance tests
with the rest of the assertions on, to help catch bugs in higher level
code. There's maybe three major categories of these people might want
to turn off, right? If you consider wal_debug as an example of
something similar that's already there, the footprint of supporting that is:
-15 lines in config.sgml
-12 lines in guc.c
-4 lines in xlog.c
Plus all the places that have the #IFDEF around them to only enable if
this is on, which is the same regardless of the UI to toggle it. So
there'd be ~35 lines of new code per option to add them in the same way,
as GUCs you can view but not set, and that aren't included in the
postgresql.conf.sample and such.
Right now --enable-cassert => debug_assertions makes it easy on the user
side to figure out whether they have the expensive debugging stuff
turned on from a UI everybody knows--type a psql command. I'm biased
toward just doing the minor cut/paste bloat to do something similar for
the most expensive performance bits too. Then, as this escapes into the
wild, we can continue to sort out performance reports that easily. As
I've ran into a few times now, not everybody even has pg_config
installed, because it's usually sitting in a devel package instead of
the main server one.
If it's compiler option only, no GUC, and you have to use pg_config to
figure out if you did it, that's completely acceptable too. I don't
have a strong opinion here, just a preference. No arguments from me if
the decision is "that's too much code to add for something so marginal".
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us