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. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
