Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKm1X-0002aZ-0f for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2017 14:10:39 +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 1eKm1V-0004xV-Gz for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2017 14:10:37 +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 1eKm1U-0004xL-WB for pgsql-hackers@lists.postgresql.org; Fri, 01 Dec 2017 14:10:37 +0000 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eKm1R-0007bm-3S for pgsql-hackers@postgresql.org; Fri, 01 Dec 2017 14:10:35 +0000 Received: by mail-wm0-x241.google.com with SMTP id 64so3580176wme.3 for ; Fri, 01 Dec 2017 06:10:32 -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=RNAfyXYpT9gaIoc3t1oInHrEIe1/9JqsFeMVAnfKNvo=; b=xwsdPYfe9oO5bcZtJZGe28saZvYiZYmQEphjvTZQDjyD7/5aJBtS66EtyxfsnRwWTG SWkpbUXOv48LMgo63e0Hsjdh3lTHNGbeaEtrjaW7/OzTLgqaEif9LiH3qc2USD1QVjnj Xi7EstHNpgvo38bpoBqXXIQo+njXEw3ukm6yQerNI3V0yKot8sdydb8CFPigrpqsdr/E /ldVoMIgtzOMaMMNVczSLVXnergqLN2qNaPvGHxUMHR6bqhjqwv9/mpkKUxGc0maaapY p8Ri/Cgp3D1q2NfvgsjpqgqYagfuY3tadtyt7mAKlHboCBD2mkACqMCfGI0qqHAYwYba 6L6w== 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=RNAfyXYpT9gaIoc3t1oInHrEIe1/9JqsFeMVAnfKNvo=; b=tOl1fhYbzWcq3I5baIHYnA0z+a0CU4s9YnVyGDD9YMKqxJxRm8VP7ivzqC3E/0JR/I n7oA4QB8svmKzzB934+EPs0RbXYVft9syl7H+lNih3FhnixTHB/cmwBdmcOEx3WQk6Vt OvAIMzSDBNj4IYRgBy12mXpBQiI0ieZpuFSWOKpZAERgUv7FUe99DV29PhAasusbcubi y0x9LnGPovQInuXAd+wJ2RskgOkwpsjm+Fnuhww4jTGDHdDGRcfKYOwS+EMKYMNfoEaO kVhTHPG80FiCUkGG1K0/cIa0GmsD+oHYvC+FI5uJ54WPrmkClfwJ2TIk1GCgaVp4AfZ3 Extw== X-Gm-Message-State: AJaThX4Pl1WERA+5stiAky7ZvY6zE/uOo2HwxzAg/JVIOOPaBfZTu5Hp nHAoWk/L2tg73TOEACetj3qynQ== X-Google-Smtp-Source: AGs4zMbsgVu0mayIKXQRW76VtViAMSODpkdLdVoh1OkXpMZlfxjG2gMGroh0H4txdVNEtzlsv0Ajxg== X-Received: by 10.28.57.11 with SMTP id g11mr1393150wma.92.1512137431169; Fri, 01 Dec 2017 06:10:31 -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 l142sm1222724wmb.43.2017.12.01.06.10.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 06:10:26 -0800 (PST) Subject: Re: [HACKERS] Custom compression methods To: Alvaro Herrera Cc: Ildus Kurbangaliev , pgsql-hackers@postgresql.org, Ildar Musin References: <20171130205155.7mgq2cuqv6zxi25a@alvherre.pgsql> From: Tomas Vondra Message-ID: <6ac2d002-94a7-feab-301d-e790417b43a9@2ndquadrant.com> Date: Fri, 1 Dec 2017 15:10:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171130205155.7mgq2cuqv6zxi25a@alvherre.pgsql> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 11/30/2017 09:51 PM, Alvaro Herrera wrote: > Tomas Vondra wrote: > >> On 11/30/2017 04:20 PM, Ildus Kurbangaliev wrote: > >>> CREATE COMPRESSION METHOD ts1 FOR tsvector HANDLER >>> tsvector_compression_handler; >> >> Understood. Good to know you've considered it, and I agree it doesn't >> need to be there from the start (which makes the patch simpler). > > Just passing by, but wouldn't this fit in the ACCESS METHOD group of > commands? So this could be simplified down to > CREATE ACCESS METHOD ts1 TYPE COMPRESSION > we have that for indexes and there are patches flying for heap storage, > sequences, etc. I think that's simpler than trying to invent all new > commands here. Then (in a future patch) you can use ALTER TYPE to > define compression for that type, or even add a column-level option to > reference a specific compression method. > I think that would conflate two very different concepts. In my mind, access methods define how rows are stored. Compression methods are an orthogonal concept, e.g. you can compress a value (using a custom compression algorithm) and store it in an index (using whatever access method it's using). So not only access methods operate on rows (while compression operates on varlena values), but you can combine those two things together. I don't see how you could do that if both are defined as "access methods" ... Furthermore, the "TYPE" in CREATE COMPRESSION method was meant to restrict the compression algorithm to a particular data type (so, if it relies on tsvector, you can't apply it to text columns). Which is very different from "TYPE COMPRESSION" in CREATE ACCESS METHOD. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services