Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id DE9C12E0054 for ; Fri, 18 Apr 2008 16:51:18 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 92492-01 for ; Fri, 18 Apr 2008 16:51:12 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by developer.postgresql.org (Postfix) with ESMTP id A4F0D2E0044 for ; Fri, 18 Apr 2008 16:51:15 -0300 (ADT) Received: from [80.229.150.39] (helo=mansionfamily.plus.com) by pih-relay04.plus.net with esmtp (Exim) id 1Jmwc5-0006ws-Ar for pgsql-performance@postgresql.org; Fri, 18 Apr 2008 20:51:13 +0100 Received: from [192.168.0.87] ([192.168.0.87]:3423) by mansionfamily.plus.com with [XMail 1.22 ESMTP Server] id for from ; Fri, 18 Apr 2008 20:56:36 +0100 Message-ID: <4808FCB3.7090904@mansionfamily.plus.com> Date: Fri, 18 Apr 2008 20:55:31 +0100 From: James Mansion Organization: MsgWare User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: full_page_write and also compressed logging Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Plusnet-Relay: 7ec31cfb8a85495569ac6bae9b6a2bb5 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/281 X-Sequence-Number: 29774 Has there ever been any analysis regarding the redundant write overhead of full page writes? I'm wondering if once could regard an 8k page as being 64 off 128 byte paragraphs or 32 off 256byte paragraphs, each represented by a bit in a word. And, when a pageis dirtied by changes some record is kept of this based on the paragraphs affected. Then you could just incrementally dump the pre-image of newly dirtied paragraphs as you go, and the cost in terms of dirtied pages would be much lower for the case of scattered updates. (I was also wondering about just doing preimages based on chaned byte ranges but the approach above is probably faster, doesn't dump the same range twice, and may fit the existing flow more directly) Also - has any attempt been made to push log writes through a cheap compressor, such a zlib on lowest setting or one like Jeff Bonwick's for ZFS (http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/compress.c). Would work well for largely textual tables (and I suspect a lot of integer data too). James