From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: preload dictionary new version |
Date: | 2010-07-12 00:47:57 |
Message-ID: | AANLkTim0wGYySF85U_AjcXTnzo_gkUghJc13SaC2DbcS@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/7/8 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
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.
> I like the idea of a precompiler step mainly because it still gives you
> most of the benefits of the patch on platforms without mmap.
I also like the precompiler solution. I think the most important benefit
in the approach is that we don't need to declare dictionaries to be preloaded
in configuration files; We can always use mmap() for all dictionary files.
--
Takahiro Itagaki
From | Date | Subject | |
---|---|---|---|
Next Message | Itagaki Takahiro | 2010-07-12 02:30:40 | Re: patch (for 9.1) string functions |
Previous Message | Tom Lane | 2010-07-11 23:37:18 | crash-recovery replay of CREATE TABLESPACE is broken in HEAD |