Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEthQ-0003oe-LZ for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Nov 2017 09:09:37 +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 1eEthP-0006tm-Po for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Nov 2017 09:09:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eEthP-0006tc-Ih for pgsql-hackers@lists.postgresql.org; Wed, 15 Nov 2017 09:09:35 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1eEthL-00005U-Ms for pgsql-hackers@postgresql.org; Wed, 15 Nov 2017 09:09:34 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id DA3DD21C1CE2; Wed, 15 Nov 2017 12:09:29 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Received: from wp.localdomain (unknown [192.168.27.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 6670D21C1CC9; Wed, 15 Nov 2017 12:09:29 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1510736969; bh=ChGVIueNxvzVrwsnI/Esu0ikTpTlNlKiIcO8G9cQX7c=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=VGv49LHEHRkMV7vZVG2DvFUPQPKaQx2i3AFfbNwVlGTegHe56bXYnAWXR725/YLnH /yhcuu5hzMHMMu4gRuL7Yyuw3DjGXYFRQQWE9tWKHKmx+3t9POnidHmTz5T9VdWj37 4YZL+uM8XS2emj1LL4+wxuaY1KoDvf5CRFFxK36U= Date: Wed, 15 Nov 2017 12:09:28 +0300 From: Ildus Kurbangaliev To: Robert Haas Cc: Oleg Bartunov , Craig Ringer , Peter Eisentraut , PostgreSQL Hackers , Andres Freund Subject: Re: [HACKERS] Custom compression methods Message-ID: <20171115120928.31bee414@wp.localdomain> In-Reply-To: References: <20170907194236.4cefce96@wp.localdomain> <20170912175505.4afa11fd@wp.localdomain> <5c84382f-1065-e9e8-dde8-4c1f5ae1007b@2ndquadrant.com> <20171102124101.5a28ecab@wp.localdomain> Organization: Postgres Professional X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, 5 Nov 2017 17:34:23 -0500 Robert Haas wrote: > On Sun, Nov 5, 2017 at 2:22 PM, Oleg Bartunov > wrote: > >> IIRC there were some concerns about what happened with pg_upgrade, > >> with consuming precious toast bits, and a few other things. > > > > yes, pg_upgrade may be a problem. > > A basic problem here is that, as proposed, DROP COMPRESSION METHOD may > break your database irretrievably. If there's no data compressed > using the compression method you dropped, everything is cool - > otherwise everything is broken and there's no way to recover. The > only obvious alternative is to disallow DROP altogether (or make it > not really DROP). In the patch I use separate table for compresssion options (because each attribute can have additional options for compression). So basicly compressed attribute linked to compression options, not the compression method and this method can be safely dropped. So in the next version of the patch I can just unlink the options from compression methods and dropping compression method will not affect already compressed tuples. They still could be decompressed. -- --- Ildus Kurbangaliev Postgres Professional: http://www.postgrespro.com Russian Postgres Company