Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKr9J-0003bG-8e for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2017 19:39:01 +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 1eKr9I-0002Fe-8s for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2017 19:39:00 +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 1eKr9H-0002FU-V9 for pgsql-hackers@lists.postgresql.org; Fri, 01 Dec 2017 19:39:00 +0000 Received: from smtprelay0103.b.hostedemail.com ([64.98.42.103] helo=smtprelay.b.hostedemail.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eKr9E-0006HD-VL for pgsql-hackers@postgresql.org; Fri, 01 Dec 2017 19:38:58 +0000 Received: from filter.hostedemail.com (10.5.19.248.rfc1918.com [10.5.19.248]) by smtprelay04.b.hostedemail.com (Postfix) with ESMTP id 5FBC67B88C; Fri, 1 Dec 2017 19:38:55 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,alvherre@alvh.no-ip.org,:::::::,RULES_HIT:41:355:379:599:967:973:988:989:1260:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1542:1593:1594:1595:1596:1711:1730:1747:1777:1792:2393:2525:2560:2563:2682:2685:2828:2859:2901:2918:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4605:5007:6119:6261:7809:7903:9025:9121:10004:10400:10848:11232:11658:11914:12663:12740:12895:13161:13229:13439:13894:13895:21080:21325:21433:21627:30054:30062,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:1,LUA_SUMMARY:none X-HE-Tag: plane05_13918a526f22b X-Filterd-Recvd-Size: 3221 Received: from alvin.alvh.no-ip.org (unknown [190.162.169.188]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf13.b.hostedemail.com (Postfix) with ESMTPA; Fri, 1 Dec 2017 19:38:54 +0000 (UTC) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id D3D23AAC; Fri, 1 Dec 2017 16:38:42 -0300 (-03) Date: Fri, 1 Dec 2017 16:38:42 -0300 From: Alvaro Herrera To: Tomas Vondra Cc: Ildus Kurbangaliev , pgsql-hackers@postgresql.org, Ildar Musin Subject: Re: [HACKERS] Custom compression methods Message-ID: <20171201193842.c47t6tyi72rhgdll@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6ac2d002-94a7-feab-301d-e790417b43a9@2ndquadrant.com> User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Tomas Vondra wrote: > On 11/30/2017 09:51 PM, Alvaro Herrera wrote: > > 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 would conflate two very different concepts. In my mind, > access methods define how rows are stored. In mine, they define how things are accessed (i.e. more general than what you're thinking). We *currently* use them to store rows [in indexes], but there is no reason why we couldn't expand that. So we group access methods in "types"; the current type we have is for indexes, and methods in that type define how are indexes accessed. This new type would indicate how would values be compressed. I disagree that there is no parallel there. I'm trying to avoid pointless proliferation of narrowly defined DDL commands. > 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). Yes, of course. I'm saying that the "datatype" property of a compression access method would be declared somewhere else, not in the TYPE clause of the CREATE ACCESS METHOD command. Perhaps it makes sense to declare that a certain compression access method is good only for a certain data type, and then you can put that in the options clause, "CREATE ACCESS METHOD hyperz TYPE COMPRESSION WITH (type = tsvector)". But many compression access methods would be general in nature and so could be used for many datatypes (say, snappy). To me it makes sense to say "let's create this method which is for data compression" (CREATE ACCESS METHOD hyperz TYPE COMPRESSION) followed by either "let's use this new compression method for the type tsvector" (ALTER TYPE tsvector SET COMPRESSION hyperz) or "let's use this new compression method for the column tc" (ALTER TABLE ALTER COLUMN tc SET COMPRESSION hyperz). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services