Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMbID-0005x7-Cc for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Dec 2017 15:07:26 +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 1eMbID-0001Y8-0d for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Dec 2017 15:07:25 +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 1eMbIC-0001Xq-LI for pgsql-hackers@lists.postgresql.org; Wed, 06 Dec 2017 15:07:24 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1eMbI8-000059-Is for pgsql-hackers@postgresql.org; Wed, 06 Dec 2017 15:07:24 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 1C6C121C1D2A; Wed, 6 Dec 2017 18:07:18 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru Received: from localhost.localdomain (unknown [31.173.148.242]) (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 A0A2B21C1690; Wed, 6 Dec 2017 18:07:17 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1512572837; bh=ICMiFRz2wejwRFxCT28t1694QdPdPfvKO7dDC1sgavQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=XH84RehLyfPbydjUktvUDC8uIIApn/+tM5QGico3ElKBrMhVBzmkcYES6q8SrloC/ mfk6lrsxIerfyWUTFUkqYADETDmdvplXP9C+vTsBjrD28ZKvVHrAdubgS5lGAOc2AT 8QFVNJDu6bQ1qJfivvqXXfFKX8azDMjrtqmqkg1I= Date: Wed, 6 Dec 2017 18:07:16 +0300 From: Ildus Kurbangaliev To: Tomas Vondra Cc: Alvaro Herrera , =?UTF-8?B?0JXQstCz0LXQvdC4?= =?UTF-8?B?0Lkg0KjQuNGI0LrQuNC9?= , Andres Freund , Robert Haas , Oleg Bartunov , Craig Ringer , Peter Eisentraut , PostgreSQL Hackers Subject: Re: [HACKERS] Custom compression methods Message-ID: <20171206180716.75ba9ba9@postgrespro.ru> In-Reply-To: References: <20171201194859.le5hvnnrjzhxhm2t@alvherre.pgsql> 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 Fri, 1 Dec 2017 21:47:43 +0100 Tomas Vondra wrote: > > +1 to do the rewrite, just like for other similar ALTER TABLE commands Ok. What about the following syntax: ALTER COLUMN DROP COMPRESSION - removes compression from the column with the rewrite and removes related compression options, so the user can drop compression method. ALTER COLUMN SET COMPRESSION NONE for the cases when the users want to just disable compression for future tuples. After that they can keep compressed tuples, or in the case when they have a large table they can decompress tuples partially using e.g. UPDATE, and then use ALTER COLUMN DROP COMPRESSION which will be much faster then. ALTER COLUMN SET COMPRESSION WITH will change compression for new tuples but will not touch old ones. If the users want the recompression they can use DROP/SET COMPRESSION combination. I don't think that SET COMPRESSION with the rewrite of the whole table will be useful enough on any somewhat big tables and same time big tables is where the user needs compression the most. I understand that ALTER with the rewrite sounds logical and much easier to implement (and it doesn't require Oids in tuples), but it could be unusable. -- ---- Regards, Ildus Kurbangaliev