From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: COPY ENCODING revisited |
Date: | 2011-02-18 03:42:17 |
Message-ID: | AANLkTikPM3JrgzNiNppmwWDQ8OBWV9Mz8t_qOXjCCS6T@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 18, 2011 at 04:04, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
> FWIW, I finally found the good example to cache miscellaneous data in
> file local, namely regexp.c. It allocates compiled regular expressions
> up to 32 by using malloc().
I'm not exactly sure the cache usage in mbutils.c because it doesn't have
routine for cache invalidation at all. Conversion procs are rarely
replaced, but we might not ought to keep cached functions unlimitedly.
Regexp cache is OK because the algorithm cannot be modified at runtime.
> We need only 4 or so for encoding
> conversion cache, in which cache search doesn't seem like overhead.
We need to research what we should cache for conversion procs.
We will need 4 bytes per conversion pair if we cache only OIDs,
but sizeof(FmgrInfo) bytes if we use the same way as ToXXXConvProc cache.
--
Itagaki Takahiro
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-02-18 03:45:29 | Re: Initial review of xslt with no limits patch |
Previous Message | Bruce Momjian | 2011-02-18 03:41:17 | Re: Initial review of xslt with no limits patch |