Re: patch: preload dictionary new version
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Itagaki Takahiro <itagaki.takahiro@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2010-07-12T07:30:25Z
Lists: 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 >