>> Hmm, good point; I presume "accept the fact that settings change won't
>> propagate to other backends until reconnect" would not be acceptable
>> behavior, even if documented along with the relevant configuration option?
> I suppose so. That was one of the reasons to move tsearch into core and it will
> be too regrettable to lost that feature again.
The whole idea is pretty much a nonstarter anyway, because the only
place to "preload" dictionaries would be in the postmaster process.
That will never fly for several reasons:
1. The postmaster doesn't have database access and so couldn't read
the dictionary definition.
2. If it did have database access, it wouldn't know which database
of the cluster to look in.
3. The point of the postmaster process is to be so simple as to be
nearly crashproof. We would never accept a patch that made it execute
dictionary-loading code, because of the likely impact on system
reliability. (This is in fact the reason behind point #1.)
4. The approach would never work anyway on Windows, since that platform
does fork/exec not just fork.
What I think *is* worth doing is spending some time on making dictionary
loading go faster. Has any focused profiling and optimization effort
been spent on that code at all? One idea is to precompile the
text-based config files into some format designed to load fast.
(But it'd be premature to adopt that idea without some profiling
results to prove where the bottleneck is.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
No comments:
Post a Comment