Re: patch: preload dictionary new version
От | Pavel Stehule |
---|---|
Тема | Re: patch: preload dictionary new version |
Дата | |
Msg-id | AANLkTikhi3jlPpkxl_a0Uo8NdsxUxVILVkud4NSyOeMA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch: preload dictionary new version (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2010/7/12 Tom Lane <tgl@sss.pgh.pa.us>: > Itagaki Takahiro <itagaki.takahiro@gmail.com> writes: >> 2010/7/8 Tom Lane <tgl@sss.pgh.pa.us>: >>> For example, the dictionary-load code could automatically execute >>> the precompile step if it observed that the precompiled copy of the >>> dictionary was missing or had an older file timestamp than the source. I am not sure, but it can be recompiled when tseach code is actualised (minor update) too. > >> There might be a problem in automatic precompiler -- Where should we >> save the result? OS users of postgres servers don't have write-permission >> to $PGSHARE in normal cases. Instead, we can store the precompiled >> result to $PGDATA/pg_dict_cache or so. > > Yeah. Actually we'd *have* to do something like that because $PGSHARE > should contain only architecture-independent files, while the > precompiled files would presumably have dependencies on endianness etc. > It is file and can be broken - so we have to check its consistency. There have to some evidency of dictionaries in cache - how will be identified a precompiled file? We cannot use a dictionary name, because it is a combination of dictionary and stop words. Have to have to thinking about filenames length here? Will be beter some generated name and a new system table? Regards Pavel Stehule > regards, tom lane >
В списке pgsql-hackers по дате отправления: