Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKsic-0000iB-RJ for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2017 21:19:34 +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 1eKsic-0006Cb-EV for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2017 21:19:34 +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 1eKsic-0006CQ-4p for pgsql-hackers@lists.postgresql.org; Fri, 01 Dec 2017 21:19:34 +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 1eKsiZ-0008UB-JY for pgsql-hackers@postgresql.org; Fri, 01 Dec 2017 21:19:32 +0000 Received: by mail-wm0-x241.google.com with SMTP id t8so5767374wmc.3 for ; Fri, 01 Dec 2017 13:19:31 -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=/q1YfZKe90TLuPMnT59jj0lN1dXp/4UozpNVJcQCfxE=; b=vSg+jc+1P3MllHyWcZ5J9e2i2r5Je5A3FltNlXg7jY2T4C6zr2zxNjKUdI/i2CUAwz ONKofSDt3l+kz6Lbwg+fyGbVJCe10LIb78aw5yvZpjEu+jcPCWxrC0TpvjXaMgpeb/Td mg/kG5GquBy/I3HweOSM9dbPSbjnCqVvsubSGekeho5g4IJV+wejFHh5LGCTtDs3KDtG 95doLC38ZLmNrBB4FTZGi6F26DX82IujGCJdAEzjCdhgv0O/BAjsIJtS4qzxrob+t2JW p7rcUslTDN8joBvP/us5uG8cCjg3XEV7AVIndsdvwE0IzFJXxV1GpTuzXuXJmqmJ405j 0mQA== 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=/q1YfZKe90TLuPMnT59jj0lN1dXp/4UozpNVJcQCfxE=; b=KexwkcZRgluYO0SE37X2gdQ6EBaABHpBa4XiGfedL0dybsEDjehl8W2VQ5qD9rCf7x 7cHE/C7ealF/5kmrdTgaKTVqv/zL75Zbhbg9RIATkNTy0/DvQiL0BrfVXZtM+PHFmTtE G9w2sfRhyndVUU3ajDESOsZayni4ua3rHfEgCf3bze45lHz03JHLdcYjY5qfXQgWJvDy Rmvf2eHkJ1sSCxwWk7eHUYLOqJfoP4Ss9TKC3Gkyoy1OQzvwsfiKkAMI6l+EmYV49e4N ZDveT8/tyaRlSBDFkSaYPdpoI3Y6el4h6nI3zyawUwoXFjHoEcuCDmzQXRfJb/GpkZ5V wFFw== X-Gm-Message-State: AJaThX5hNnMMEKjbNFOMAXo3EjE8NbRMRelx1m263HVM2t5y1ASiAGl2 Z9behBQViZlI7uqR+FRUqzedXw== X-Google-Smtp-Source: AGs4zMYo4+TT9VBQutxszsIKfT0HzEAwlZK9IT/I43r2gwg72tZyjK7zvujVl4GcE4Zgg6GfzBQ09g== X-Received: by 10.28.99.131 with SMTP id x125mr2036632wmb.32.1512163169920; Fri, 01 Dec 2017 13:19:29 -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 90sm11550474wrp.93.2017.12.01.13.19.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 13:19:29 -0800 (PST) Subject: Re: [HACKERS] Custom compression methods To: Alvaro Herrera Cc: Ildus Kurbangaliev , pgsql-hackers@postgresql.org, Ildar Musin References: <20171201193842.c47t6tyi72rhgdll@alvherre.pgsql> From: Tomas Vondra Message-ID: Date: Fri, 1 Dec 2017 22:19:26 +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: <20171201193842.c47t6tyi72rhgdll@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 12/01/2017 08:38 PM, Alvaro Herrera wrote: > 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. > Not sure I follow. My argument was not as much about whether the rows are stored as rows or in some other (columnar) format, but that access methods deal with "tuples" (i.e. row in the "logical" way). I assume that even if we end up implementing other access method types, they will still be tuple-based. OTOH compression methods (at least as introduced by this patch) operate on individual values, and have very little to do with access to the value (in a sense it's a transparent thing). > > 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. > Of course, the opposite case is using the same DDL for very different concepts (although I understand you don't see it that way). But in fairness, I don't really care if we call this COMPRESSION METHOD or ACCESS METHOD or DARTH VADER ... >> 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). > The WITH syntax does not seem particularly pretty to me, TBH. I'd be much happier with "TYPE tsvector" and leaving WITH for the options specific to each compression method. FWIW I think syntax is the least critical part of this patch. It's ~1% of the patch, and the gram.y additions are rather trivial. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services