Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w52kB-002q0y-1p for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2026 14:28:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w52kA-007DFR-0K for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2026 14:28:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w52k9-007DF8-23 for pgsql-hackers@lists.postgresql.org; Tue, 24 Mar 2026 14:28:30 +0000 Received: from forward101a.mail.yandex.net ([178.154.239.84]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w52k7-00000000tGp-0WnJ for pgsql-hackers@postgresql.org; Tue, 24 Mar 2026 14:28:29 +0000 Received: from mail-nwsmtp-smtp-production-main-92.vla.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-92.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1f:251b:0:640:cb7f:0]) by forward101a.mail.yandex.net (Yandex) with ESMTPS id 2CD9B80DCD; Tue, 24 Mar 2026 17:28:26 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-92.vla.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id OSUm2rJGf4Y0-meNAdvyG; Tue, 24 Mar 2026 17:28:25 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tantorlabs.com; s=mail; t=1774362505; bh=cfd6z+GZQpiIFa4WLfGHrR3oeOTQkMwrVDPRpujYO+w=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=N5s7LwVS6fKwyMNcGA5zyBaQGLbTwIwPZolwXlkaUQuLEavoq2dGfku5TqI0oA2+X wcsm2LPE/tXQoDQDnTQcbBWv6HHtHcT/YLYUfOIuxtvVYxe5pLyjXvgL4ihm5ubB/i jYxK6tVOzRvuGMIHjt5sZx2eM0DdkjdQshHakWf8= Authentication-Results: mail-nwsmtp-smtp-production-main-92.vla.yp-c.yandex.net; dkim=pass header.i=@tantorlabs.com Message-ID: Date: Tue, 24 Mar 2026 22:28:24 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Compress prune/freeze records with Delta Frame of Reference algorithm To: Andres Freund , PostgreSQL Hackers , Andrey Borodin References: Content-Language: en-US From: Evgeny Voropaev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello Andres, > I'm unconvinced that this is a serious problem - typically the overhead of WAL > volume due to pruning / freezing is due to the full page images emitted, not > the raw size of the records. Once an FPI is emitted, this doesn't matter. > > What gains have you measured in somewhat realistic workloads? So far, we have had no tests in any real production environment. Moreover, the load in the new test (recovery/t/052_prune_dfor_compression.pl) is quite contrived. However, it demonstrates a compression ratio of more than 5, and it is measured for an overall size of all prune/freeze records with no filtering. Further development is the implementation of compression of unsorted sequences. This is going to allow PostgreSQL to compress also the 'frozen' and the 'redirected' offset sequences, which should result in a greater compression ratio. But I agree with you, Andres, we need practical results to estimate a profit. I wish we would test it on some real load soon. Also I hope, independently of its usage in prune/freeze records, the DFoR itself might be used for compression sequences in other places of PG. Best regards, Evgeny Voropaev.