Re: easy way of copying regex_t

From: Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: easy way of copying regex_t
Date: 2016-01-25 11:33:05
Message-ID: 56A607F1.2040303@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25.01.2016 13:07, Tomas Vondra wrote:
>
> Right, it's definitely not thread-safe so there'd need to be some lock
> protecting the regex_t copy. I was thinking about either using a group
> of locks, each protecting a small subset of the affixes (thus making it
> possible to work in parallel to some extent), or simply using a single
> lock and each process would make a private copy at the beginning.
>
> In the end, I've decided to do it differently, and simply parse the
> affix list from scratch in each process. The affix list is tiny and
> takes less than a millisecond to parse in most cases, and I don't have
> to care about the regex stuff at all. The main benefit is from sharing
> parsed wordlist anyway.

This is nice decision since the affix list is small. For our task I will
change shared_ispell to use this solution.

>
> It's an old-school shared segment created by the extension at init time.
> You're right the size is fixed so it's possible to run out of space by
> loading too many dictionaries, but that was not a big deal for the type
> of setups it was designed for - in those cases the list of dictionaries
> is stable, so it's possible to size the segment accordingly in advance.
>
> But I guess we could do better now that we have dynamic shared memory,
> possibly allocating one segment per dictionary as needed, or something
> like that.
>
> regards
>

Yes it would be better as we will not need to define the maximum size of
the shared segment in postgresql.conf.

--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vinayak Pokale 2016-01-25 11:58:06 Re: [PROPOSAL] VACUUM Progress Checker.
Previous Message Amit Langote 2016-01-25 10:32:53 Re: Declarative partitioning