Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eKsDw-0007RZ-Nn for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2017 20:47:52 +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 1eKsDw-0003Xj-As for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2017 20:47:52 +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 1eKsDw-0003XZ-4a for pgsql-hackers@lists.postgresql.org; Fri, 01 Dec 2017 20:47:52 +0000 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eKsDt-0006u6-5M for pgsql-hackers@postgresql.org; Fri, 01 Dec 2017 20:47:51 +0000 Received: by mail-wm0-x241.google.com with SMTP id g75so5717465wme.0 for ; Fri, 01 Dec 2017 12:47:48 -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=ALOqegKdn7plqxZYlYJffFgCYCQ5Mb7Qyr5nJIdDMOY=; b=drR95BnWGNsLFeAEONfYGwLrGWyi4dkMaL4pqBsqDr7uOBLB/YFH7KeiTN1bIWEuoD MkEHFWOrV+USVwXFHhdBDWzgjJCToAZ+EGZIC7gZk0HFrFkiekh1MkrtiZTspG40pWbM /3Wmk4s2RrFx00WFcElWUTBVZXmECByQzqPO2E9LEzpBNAZoczMw28VhcXgpzZdIOqex N9g0pe0XcRbGtVheKbshVQQRbDCJBzSdXWWAM9ytKIFxvjTKcCjQVtio430jXtoKfnbh LKeFzwpIGak8s2h37J/yu0KNKictsfdaDdPxb/0uMVJvjxkhQ0XneNZcAhqtXkRR7pAb jfBA== 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=ALOqegKdn7plqxZYlYJffFgCYCQ5Mb7Qyr5nJIdDMOY=; b=iKU8q5gB1CcBvC8qz68frvsZmpB9IIxd8aTQ0TEW09AaHHIhveIL80gA2slM5mL43R KJbqsxlrQpyqS41FuFwRufQ9R0Zez6ZC+zFvQ4IU6iCALAMqBzH0OMjkP3QSIV7nWhal hoDjdWC48DQMxstqA7YOaM7ffC5/uDIxwIOMs4sSIe0iNBwhdYvDQhdZNkXjw/49tw3L xE7yIT1A1ISzvN0jTLZJh6MvEfVsWTxmMg6npcJKh7dLvaeQxdSODIyjdHnaAFz1qV4f MJuGCj9x8rQV7v8CAUev4qnAWipekk39Gn3nKjGJ6Uof8xCZd7JbPxjNq8taqLZc5FM7 NWAw== X-Gm-Message-State: AKGB3mKvz1s3jSYrfZ6phMGmG3OuH+X/Y5dCb4Tur9cJ+dxMNHy+JSef YBpWAQfx/MZTjwCQhV7R6jiS7EEIePEd3ZibyUjyBsnbmOQwXkomIdCAKobXE4lJkBQNbQq8qUy dGYuh2i/FOf2djmqvGc+wAS7Go/O6gqVz6X5kpqM5s7KsjzGqyPZoy+YATdPUokNBxVQYlGZQE9 +WucArhIbK X-Google-Smtp-Source: AGs4zMbkEO+vfO8aqBevR0dglH/As63R4q0spTzMtgNnTcB4aHhLEoZvXLJB0zhEikASpdtF9v7SYw== X-Received: by 10.28.168.133 with SMTP id r127mr2101939wme.83.1512161267559; Fri, 01 Dec 2017 12:47:47 -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 s30sm8659398wrc.89.2017.12.01.12.47.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 12:47:46 -0800 (PST) Subject: Re: [HACKERS] Custom compression methods To: Alvaro Herrera , Ildus Kurbangaliev Cc: =?UTF-8?B?0JXQstCz0LXQvdC40Lkg0KjQuNGI0LrQuNC9?= , Andres Freund , Robert Haas , Oleg Bartunov , Craig Ringer , Peter Eisentraut , PostgreSQL Hackers References: <20171201194859.le5hvnnrjzhxhm2t@alvherre.pgsql> From: Tomas Vondra Message-ID: Date: Fri, 1 Dec 2017 21:47:43 +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: <20171201194859.le5hvnnrjzhxhm2t@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:48 PM, Alvaro Herrera wrote: > Ildus Kurbangaliev wrote: > >> If the table is big, decompression could take an eternity. That's why i >> decided to only to disable it and the data could be decompressed using >> compression options. >> >> My idea was to keep compression options forever, since there will not >> be much of them in one database. Still that requires that extension is >> not removed. >> >> I will try to find a way how to recompress data first in case it moves >> to another table. > > I think what you should do is add a dependency between a column that > compresses using a method, and that method. So the method cannot be > dropped and leave compressed data behind. Since the method is part of > the extension, the extension cannot be dropped either. If you ALTER > the column so that it uses another compression method, then the table is > rewritten and the dependency is removed; once you do that for all the > columns that use the compression method, the compression method can be > dropped. > +1 to do the rewrite, just like for other similar ALTER TABLE commands > > Maybe our dependency code needs to be extended in order to support this. > I think the current logic would drop the column if you were to do "DROP > COMPRESSION .. CASCADE", but I'm not sure we'd see that as a feature. > I'd rather have DROP COMPRESSION always fail instead until no columns > use it. Let's hear other's opinions on this bit though. > Why should this behave differently compared to data types? Seems quite against POLA, if you ask me ... If you want to remove the compression, you can do the SET NOT COMPRESSED (or whatever syntax we end up using), and then DROP COMPRESSION METHOD. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services