Re: [PROPOSAL] Shared Ispell dictionaries

From: Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] Shared Ispell dictionaries
Date: 2019-02-21 13:28:29
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 21.02.2019 15:45, Robert Haas wrote:
> On Wed, Feb 20, 2019 at 9:33 AM Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> wrote:
>> I'm working on the (b) approach. I thought about a priority queue
>> structure. There no such ready structure within PostgreSQL sources
>> except binaryheap.c, but it isn't for concurrent algorithms.
> I don't see why you need a priority queue or, really, any other fancy
> data structure. It seems like all you need to do is somehow set it up
> so that a backend which doesn't use a dictionary for a while will
> dsm_detach() the segment. Eventually an unused dictionary will have
> no remaining references and will go away.

Hm, I didn't think in this way. Agree that using a new data structure is

Now in the current patch all DSM segments are pinned (and therefore
dsm_pin_segment() is called). So a dictionary lives in shared memory
even if nobody have the reference to it.

I thought about periodically scanning the shared hash table and
unpinning old and unused dictionaries. But this approach needs
sequential scan facility for dshash. Happily there is the patch from
Kyotaro-san (the v16-0001-sequential-scan-for-dshash.patch part):

Your approach looks simpler. It is necessary just to periodically scan
dictionaries' cache hash table and not call dsm_pin_segment() when a DSM
segment initialized. It also means that a dictionary is loaded into DSM
only while there is a backend which attached the dictionary's DSM.

Arthur Zakirov
Postgres Professional:
Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2019-02-21 13:50:38 Re: WAL insert delay settings
Previous Message Ants Aasma 2019-02-21 13:06:58 Re: WAL insert delay settings