Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eA0Ee-0004W8-Uy for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Nov 2017 21:07:41 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eA0Ee-0001Ga-Ba for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Nov 2017 21:07:40 +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 1eA0D5-0006x8-1Z for pgsql-hackers@postgresql.org; Wed, 01 Nov 2017 21:06:03 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eA0D2-0003ia-6O for pgsql-hackers@postgresql.org; Wed, 01 Nov 2017 21:06:01 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BF70020DB8; Wed, 1 Nov 2017 17:05:58 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 01 Nov 2017 17:05:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=y0cE7L IQNjzFeyxtpXmOUwCRkpQEw2Nln/LxmunBeQk=; b=ekqwNrjKMHJItQv2OrybbL TZBrfM6OiEf/5TTKqUMspnUUhVUawHkuQxazXCo5tQJZXc/VOpsbLHuagygepszG LCchJLgjvocFKwMKmamcPobJkQNiKYhMee79ak2lN8nGBDiaApTy5gtBBKu7pNpm gcLW7fabPSGM7uPbahSsbHL+Ev78bLBSNeR1EFxTCNuDGu63dYURXEj5kRvyoggu LOo8/5TCZ5m9NCXnDO0oONKfvn/83oKjUAtuVm3LCTBTKQWzUorUp/um2lNZVBFL GnwKJJVOYu/zt8jo3oFFMxuZH630hKJMsL1TfRfKOluHWT53IzK1cbL/BxvV2D7Q == X-ME-Sender: Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 8254C249EC; Wed, 1 Nov 2017 17:05:58 -0400 (EDT) Subject: Re: Custom compression methods To: Ildus Kurbangaliev , pgsql-hackers@postgresql.org References: <20170907194236.4cefce96@wp.localdomain> <20170912175505.4afa11fd@wp.localdomain> From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <5c84382f-1065-e9e8-dde8-4c1f5ae1007b@2ndquadrant.com> Date: Wed, 1 Nov 2017 17:05:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20170912175505.4afa11fd@wp.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 9/12/17 10:55, Ildus Kurbangaliev wrote: >> The patch also includes custom compression method for tsvector which >> is used in tests. >> >> [1] >> https://www.postgresql.org/message-id/CAPpHfdsdTA5uZeq6MNXL5ZRuNx%2BSig4ykWzWEAfkC6ZKMDy6%3DQ%40mail.gmail.com > Attached rebased version of the patch. Added support of pg_dump, the > code was simplified, and a separate cache for compression options was > added. I would like to see some more examples of how this would be used, so we can see how it should all fit together. So far, it's not clear to me that we need a compression method as a standalone top-level object. It would make sense, perhaps, to have a compression function attached to a type, so a type can provide a compression function that is suitable for its specific storage. The proposal here is very general: You can use any of the eligible compression methods for any attribute. That seems very complicated to manage. Any attribute could be compressed using either a choice of general compression methods or a type-specific compression method, or perhaps another type-specific compression method. That's a lot. Is this about packing certain types better, or trying out different compression algorithms, or about changing the TOAST thresholds, and so on? Ideally, we would like something that just works, with minimal configuration and nudging. Let's see a list of problems to be solved and then we can discuss what the right set of primitives might be to address them. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers