Re: [PROPOSAL] Shared Ispell dictionaries - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PROPOSAL] Shared Ispell dictionaries
Date
Msg-id 20190120222121.ehistvcr4wsu2su5@alap3.anarazel.de
Whole thread Raw
In response to Re: [PROPOSAL] Shared Ispell dictionaries  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: [PROPOSAL] Shared Ispell dictionaries  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote:
> On 1/17/19 3:15 PM, Arthur Zakirov wrote:
> > I attached files of new version of the patch, I applied your tweaks.
> > 
> >> XXX All dictionaries, but only when there's invalid dictionary?
> > 
> > I've made a little optimization. I introduced hashvalue into
> > TSDictionaryCacheEntry. Now released only DSM of altered or dropped
> > dictionaries.
> > 
> >>  > /* XXX not really a pointer, so the name is misleading */
> >>
> >> I think we don't need DictPointerData struct anymore, because only
> >> ts_dict_shmem_release function needs it (see comments above) and we only
> >> need it to hash search. I'll move all fields of DictPointerData to
> >> TsearchDictKey struct.
> > 
> > I was wrong, DictInitData also needs DictPointerData. I didn't remove
> > DictPointerData, I renamed it to DictEntryData. Hope that it is a more
> > appropriate name.
> > 
> 
> Thanks. I've reviewed v17 today and I haven't discovered any new issues
> so far. If everything goes fine and no one protests, I plan to get it
> committed over the next week or so.

There doesn't seem to be any docs about what's needed to be able to take
advantage of shared dicts, and how to prevent them from permanently
taking up a significant share of memory.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [PROPOSAL] Shared Ispell dictionaries
Next
From: Alexander Korotkov
Date:
Subject: Re: jsonpath