On 01/15/2018 08:02 PM, Arthur Zakirov wrote: > On Sat, Jan 13, 2018 at 10:33:14PM +0100, Tomas Vondra wrote: >> Not sure if we really need to add the database/schema OIDs. I mentioned >> the unexpected consequences (cross-db sharing) but maybe that's a >> feature we should keep (it reduces memory usage). So perhaps this should >> be another CREATE TEXT SEARCH DICTIONARY parameter, allowing sharing the >> dictionary with other databases? >> >> Aren't we overengineering this? > > Another related problem I've noticed is memory leak. When a > dictionary loaded and then dropped it won't be unloaded. >
Good point. > I see several approaches: >> 1 - Use Oid of the dictionary itself as the key instead dictfile and > afffile. When the dictionary is dropped it will be easily unloaded if it > was loaded. Implementing should be easy, but the drawback is more memory > consumption. > 2 - Use reference counter with cross-db sharing. When the dictionary is > loaded the counter increases. If all record of loaded dictionary is dropped > it will be unloaded. > 3 - Or reference counters without cross-db sharing to avoid possible > confusing. > Here dictfile, afffile and database Oid will be used as the key. > I think you're approaching the problem from the right direction, hence asking the wrong question. I think the primary question is "Do we want to share dictionaries cross databases?" and the answer will determine which of the tree options is the right one. Another important consideration is the complexity of the patch. In fact, I suggest to make it your goal to make the initial patch as simple as possible. If something is "nice to have" it may wait for v2. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
