Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eePIV-0000X6-4F for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jan 2018 17:57:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eePIU-0001f0-C8 for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jan 2018 17:57:18 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eePIU-0001eq-2D for pgsql-hackers@lists.postgresql.org; Wed, 24 Jan 2018 17:57:18 +0000 Received: from mail-wr0-x232.google.com ([2a00:1450:400c:c0c::232]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eePIP-0001HT-Vb for pgsql-hackers@postgresql.org; Wed, 24 Jan 2018 17:57:16 +0000 Received: by mail-wr0-x232.google.com with SMTP id v15so4949238wrb.8 for ; Wed, 24 Jan 2018 09:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7oJUwfUyK1wqMFPjFHGTHcSfs+jgQ+28mWPotdqzfUI=; b=P0hPmV4uTNAzBqBxTpnhlCuZos2rGwNNA7GcQYSGG5wt5gYpQfNqlANcM/UaYwaWmp LQPdsBIa1oj9SjGy7f82ELKIiLnDQTDL7A7urtuW/V2c6PMTFwxwCIwr1lgr7OoBhEHU Y6tpkNTH3EXU1yKR5//Q4xbrlPWdIz8nXH/lfVzyiriKWLYwR6W0qgF2JlXmcTkAAypG l4KasEnDNl22iviR7BSj0LbqgFOS6sKW1nib7X4f4velAAV3wenJlYtvlrbcvadqRtbt cKHW//Iwx9uaFCtYQqg51dLWNj4c/0vN3Iu1zH2KaB2ENslIKmphNO51A0+UNz1nL7H1 ZYqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7oJUwfUyK1wqMFPjFHGTHcSfs+jgQ+28mWPotdqzfUI=; b=cIVoJmWo2+X8rCnve6VACGs+wjdHcNdgtgAllwZxxK62L3KDAs3XfZaJ9FF0y5RYNG hy+efXY9nUX8WCxolxey89FwgFpJvytbsRgpnBYTkJPmkLOTt+eqVTsKnltsVQOnIknX aS4i1PLOq0Dj7HQWBOSb/7YML+6w1knZwaiwmkiYf9y2yhZxBMl6MirZNe8sjWDXQoeD BL0TwhcwzPl4wORgz+WdbenoQnXOtAf635aFWt/GKnIqcFRdnwM2TCGS+2MUN4MTBsdU CwSCVC/XNWUiX+GNIe+LYGanGyquCgDJN1nE5CU2eJPNhRqE2fqe1M24UvoKYSONj25S Z34A== X-Gm-Message-State: AKwxytc34wOKhtv1Wni6zyVwtNy9bdb9a97Wb18o4TMMDSlbDj+4auL9 vZ/FVE/I++4qP7zrL8UHYmMXWjbFqQYp7Bzo9GyBKS4/b778qwmzV/5Rl+/xKcscWJ76TN25JBM htZykcMXcJwqUTQgAxXZQRjIregd7EnBIvc6ma4uNJmeYVMj2vGuYhccgWzeR0DxliMaAA+eKph 4Bvac6acTv X-Google-Smtp-Source: AH8x225dwC3EC0Xo2qM37yS/RrnoeFlZ4YhqHrmz9XToAZcfLTKn6MGi9N4Txm2Tz3GupaVx0asPrw== X-Received: by 10.223.136.24 with SMTP id d24mr6665709wrd.203.1516816631651; Wed, 24 Jan 2018 09:57:11 -0800 (PST) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id o75sm932555wmd.12.2018.01.24.09.57.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 09:57:11 -0800 (PST) Subject: Re: [PROPOSAL] Shared Ispell dictionaries To: Arthur Zakirov Cc: pgsql-hackers References: <20171226164825.GA29922@zakirov.localdomain> <20171231152811.GA4233@arthur.localdomain> <20180107190526.GA27803@arthur.localdomain> <20180124172039.GA11210@zakirov.localdomain> From: Tomas Vondra Message-ID: <79abaac7-fbc1-05ef-342e-102001af4fca@2ndquadrant.com> Date: Wed, 24 Jan 2018 18:57:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20180124172039.GA11210@zakirov.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 01/24/2018 06:20 PM, Arthur Zakirov wrote: > On Sat, Jan 13, 2018 at 06:22:41PM +0300, Arthur Zakirov wrote: >> I think your proposals may be implemented in several patches, so >> they can be applyed independently but consistently. I suppose I >> will prepare new version of the patch with fixes and with initial >> design of new functions and commands soon. > > I attached new version of the patch. > Thanks. I don't have time to review/test this before FOSDEM, but a couple of comments regarding some of the points you mentioned. >> 3) How do I unload a dictionary from the shared memory? >> ... >> ALTER TEXT SEARCH DICTIONARY x UNLOAD >> >> 4) How do I reload a dictionary? >> ... >> ALTER TEXT SEARCH DICTIONARY x RELOAD > > I thought about it. And it seems to me that we can use functions > ts_unload() and ts_reload() instead of new syntax. We already have > text search functions like ts_lexize() and ts_debug(), and it is > better to keep consistency. This argument seems a bit strange. Both ts_lexize() and ts_debug() are operating on text values, and are meant to be executed as functions from SQL - particularly ts_lexize(). It's hard to imagine this implemented as DDL commands. The unload/reload is something that operates on a database object (dictionary), which already has create/drop/alter DDL. So it seems somewhat natural to treat unload/reload as another DDL action. Taken to an extreme, this argument would essentially mean we should not have any DDL commands because we have SQL functions. That being said, I'm not particularly attached to having this DDL now. Implementing it seems straight-forward (particularly when we already have the stuff implemented as functions), and some of the other open questions seem more important to tackle now. > I think there are to approach for ts_unload():> - use DSM's pin and unpin methods and the invalidation callback, as > it done during fixing memory leak. It has the drawback that it won't > have an immediate effect, because DSM will be released only when all > backends unpin DSM mapping. > - use DSA and dsa_free() method. As far as I understand dsa_free() > frees allocated memory immediatly. But it requires more work to do, > because we will need some more locks. For instance, what happens > when someone calls ts_lexize() and someone else calls dsa_free() at > the same time. No opinion on this yet, I have to think about it for a bit and look at the code first. >> 7) You mentioned you had to get rid of the compact_palloc0 - can you >> elaborate a bit why that was necessary? Also, when benchmarking the >> impact of this make sure to measure not only the time but also memory >> consumption. > > It seems to me that there is no need compact_palloc0() anymore. Tests > show that czech dictionary doesn't consume more memory after the > patch. > That's interesting. I'll do some additional tests to verify the finding. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services