Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
The point here is to do the work at postmaster start time. You won't
get a chance to find out whether both languages are defined in some
database or other. (This is the same thing as the point about the
UTF8 hack --- you can't tell if it's needed or not.)
w.r.t. UTF8, I guess we'll need a way of knowing if we're preloading or
not, and if so we'd need to skip the calls to GetDatabaseEncoding().
If you mean that you want to still do the UTF8 hack at backend start
time, I think you might as well not bother with any of this. That hack
in itself is slow enough to be 50% of the problem (presumably because
it's loading some modules down in there somewhere). We need to arrange
to either not do it at all or do it at preload.
I don't mean that we should do it at backend start even if we are
preloading. But you're not intending to make preloading compulsory, are
you?
The whole cost of loading that has been complained about is 1/10 of a
second per backend (or maybe more if you use both plperl and plperlu).
I'm fine with providing a preloading solution, but plenty of us who use
plperl from time to time are not disturbed by the current cost,
especially when it's used in web apps that use connection pooling, where
it disappears entirely in the noise.
Does preloading work at all in the BACKEND_EXEC case?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
