On 4/21/14, 9:52 AM, Alvaro Herrera wrote:
Alfred Perlstein wrote:
I am unsure of the true overhead of making this a runtime tunable so
pardon if I'm asking for "a lot". From the perspective of both an
OS developer and postgresql user (I am both) it really makes more
sense to have it a runtime tunable for the following reasons:
From an OS developer making this a runtime allows us to much more
easily do the testing (instead of needing two compiled versions).
From a sysadmin perspective it makes switching to/from a LOT easier
in case the new mmap code exposes a stability or performance bug.
In this case, AFAICS the only overhead of a runtime option (what we call
a GUC) is the added potential for user confusion, and the necessary
documentation. If we instead go for a compile-time option, both items
become smaller.
In any case, I don't see that there's much need for a runtime option,
really; you already know that the mmap code path is slower in FreeBSD.
You only need to benchmark both options once the FreeBSD vm code itself
is fixed, right?
In fact, it might not even need to be a configure option; I would
suggest a pg_config_manual.h setting instead, and perhaps tweaks to the
src/template/freebsd file to enable it automatically on the "broken"
FreeBSD releases. We could then, in the future, have the template
itself turn the option off for the future FreeBSD release that fixes the
problem.
That is correct, until you're in prod and suddenly one option becomes
unstable, or you want to try a quick kernel patch without rebooting.
Look, this is an argument I've lost time and time again in open source
software communities, the idea of a software option as opposed to
compile time really seems to hit people the wrong way.
I think from now on it just makes sense to sit back and let whatever
happens happen.
-Alfred
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
