Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glY7S-0002lw-Go for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Jan 2019 11:51:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1glY7R-0004qN-5p for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Jan 2019 11:51:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glY7Q-0004q3-Pr for pgsql-hackers@lists.postgresql.org; Mon, 21 Jan 2019 11:51:56 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1glY7M-0005BQ-RE for pgsql-hackers@postgresql.org; Mon, 21 Jan 2019 11:51:55 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 19FAE21DC518; Mon, 21 Jan 2019 14:51:50 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.27.237] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id D36DD21DC507; Mon, 21 Jan 2019 14:51:49 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1548071509; bh=WUsjdyo851mTNmsUWFxBR5Ct7c4Jh1pGoiV8Yv24/kg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ZhqrFrv7SBvGMOKXJ9oxBi6d5kFBMgzXNp8ZhW5uaXrleOBo7ji636kI406as+/Ws NXNlSEK3kso7A4wNxI1tUjkYXZaOAIa+qsv0xt/jJV8mOawUgXWTSiki9ufhdw9itm W9LhjCY40zc/SjUMLA0NNVaAvga1L7rlIJ3bcXHA= Subject: Re: [PROPOSAL] Shared Ispell dictionaries To: Tomas Vondra , Andres Freund Cc: Robert Haas , Tom Lane , Pavel Stehule , pgsql-hackers References: <27296.1522078068@sss.pgh.pa.us> <20180327121954.GA12726@zakirov.localdomain> <20180516113631.GA29544@zakirov.localdomain> <20180614084015.GA12451@zakirov.localdomain> <20181001092204.GA5071@zakirov.localdomain> <68aaaff6-0efe-c14b-7aee-fb110bb97f69@2ndquadrant.com> <337f7a55-58b8-4fcc-a933-5e7799fa6882@postgrespro.ru> <42b1ded6-fd44-5975-77e4-72ada1f134a2@2ndquadrant.com> <20190120222121.ehistvcr4wsu2su5@alap3.anarazel.de> <95aea959-97a1-2ded-c881-eede4e5a1f0c@2ndquadrant.com> From: Arthur Zakirov Message-ID: Date: Mon, 21 Jan 2019 14:51:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <95aea959-97a1-2ded-c881-eede4e5a1f0c@2ndquadrant.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 21.01.2019 02:43, Tomas Vondra wrote: > On 1/20/19 11:21 PM, Andres Freund wrote: >> On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote: >>> 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. >> > > Yeah, those are good points. I agree the comments might be clearer, but > essentially ispell dictionaries are shared and everything else is not. > > As for the memory consumption / unloading dicts - I agree that's > something we need to address. There used to be a way to specify memory > limit and ability to unload dictionaries explicitly, but both features > have been ditched. The assumption was that UNLOAD would be introduced > later, but that does not seem to have happened. I'll try to implement the syntax, you suggested earlier: ALTER TEXT SEARCH DICTIONARY x UNLOAD/RELOAD The main point here is that UNLOAD/RELOAD can't release the memory immediately, because some other backend may pin a DSM. The second point we should consider (I think) - how do we know which dictionary should be unloaded. There was such function earlier, which was removed. But what about adding an information in the "\dFd" psql's command output? It could be a column which shows is a dictionary loaded. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company