Hello,
I've created the new commitfest entry since the previous entry was
closed with status "Returned with feedback":
https://commitfest.postgresql.org/22/2007/
I attached new version of the patch. There are changes only in
0003-Retrieve-shared-location-for-dict-v18.patch.
I added a reference counter to shared hash tables dictionary entries. It
is necessary to not face memory bloat. It is necessary to delete shared
hash table entries if there are a lot of ALTER and DROP TEXT SEARCH
DICTIONARY.
Previous version of the patch had released unused DSM segments but left
shared hash table entries untouched.
There was refcnt before:
https://www.postgresql.org/message-id/20180403115720.GA7450%40zakirov.localdomain
But I didn't fully understand how on_dsm_detach() works.
On 22.01.2019 22:17, Tomas Vondra wrote:
> I think there are essentially two ways:
>
> (a) Define max amount of memory available for shared dictionarires, and
> come up with an eviction algorithm. This will be tricky, because when
> the frequently-used dictionaries need a bit more memory than the limit,
> this will result in trashing (evict+load over and over).
>
> (b) Define what "unused" means for dictionaries, and unload dictionaries
> that become unused. For example, we could track timestamp of the last
> time each dict was used, and decide that dictionaries unused for 5 or
> more minutes are unused. And evict those.
>
> The advantage of (b) is that it adopts automatically, more or less. When
> you have a bunch of frequently used dictionaries, the amount of shared
> memory increases. If you stop using them, it decreases after a while.
> And rarely used dicts won't force eviction of the frequently used ones.
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.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company