Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJuXP-0005Dm-Gb for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 07:45:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jJuXO-0008Pv-CH for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 07:45:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJuXO-0008Po-58 for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 07:45:18 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJuXK-0008Pk-Hd for pgsql-hackers@postgresql.org; Thu, 02 Apr 2020 07:45:17 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2B93A5C018C; Thu, 2 Apr 2020 03:45:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 02 Apr 2020 03:45:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=8iJcDI1DcnR+2PQIMT5oxucuGEQest1lzTXjKiZwt 3I=; b=vVLv2L2SbsmXU2ICH4rVMJq6wAsVbaCLDWoxY7QmSQsZVvmamyTBhvpd8 WRyfYEpQ06k8aA+/oQEeZl5BZgvQWmkuHConRX88f9LfYz9cIHil83xSkUQl9JFu VEenf+1L1rmfnpRVoFrKTbHdCl29UZliqH7ginksc2CylYcqVr7xvRA+f2GdVVo9 QwVaHcbEv/9sIfgc5ckJHnOfjbWk07F+H92Y833BsdV9EqX3rqqJac5dpPJVHRAJ OwKIkYYHVFrfls4nnO/psOBN897ah4glDokqkTMxhYauRYMLZRio0SPtWxBiOmhS wrRiR2Qz/CI/ehcLlwojYS3/krMqw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdefgdduvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffhvfhfohfkffgfgggjtgfgsehtjeertddtfeelnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnug hquhgrughrrghnthdrtghomheqnecuffhomhgrihhnpedvnhguqhhurggurhgrnhhtrdgt ohhmnecukfhppeelfedrvdegvddrvddufedrvdegudenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghuthes vdhnughquhgrughrrghnthdrtghomh X-ME-Proxy: Received: from april.pezone.net (p5df2d5f1.dip0.t-ipconnect.de [93.242.213.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 1338F328005E; Thu, 2 Apr 2020 03:45:10 -0400 (EDT) Subject: Re: Unicode normalization SQL functions From: Peter Eisentraut To: pgsql-hackers References: <6d55838c-9353-486f-a508-77ee07d59667@manitou-mail.org> <620b155b-a89c-d8e0-3cbb-315c3ca538f4@2ndquadrant.com> <7052cc8f-0164-72a8-d9a4-fd32066c938e@2ndquadrant.com> Cc: Daniel Verite , Andreas Karlsson Organization: 2ndQuadrant Message-ID: Date: Thu, 2 Apr 2020 09:45:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7052cc8f-0164-72a8-d9a4-fd32066c938e@2ndquadrant.com> Content-Type: text/plain; charset=iso-8859-15; 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 2020-03-26 08:25, Peter Eisentraut wrote: > On 2020-03-24 10:20, Peter Eisentraut wrote: >> Now I have some concerns about the size of the new table in >> unicode_normprops_table.h, and the resulting binary size. At the very >> least, we should probably make that #ifndef FRONTEND or something like >> that so libpq isn't bloated by it unnecessarily. Perhaps there is a >> better format for that table? Any ideas? > > I have figured this out. New patch is attached. > > First, I have added #ifndef FRONTEND, as mentioned above, so libpq isn't > bloated. Second, I have changed the lookup structure to a bitfield, so > each entry is only 32 bits instead of 64. Third, I have dropped the > quickcheck tables for the NFD and NFKD forms. Those are by far the > biggest tables, and you still get okay performance if you do the > normalization check the long way, since we don't need the recomposition > step on those cases, which is by far the slowest part. The main use > case of all of this, I expect, is to check for NFC normalization, so > it's okay if the other variants are not optimized to the same extent. I have committed this version. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services