Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gZXOV-0007HG-7d for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Dec 2018 08:39:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gZXOT-0004CA-Q9 for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Dec 2018 08:39:53 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1gZXOS-0004C3-OH for pgsql-hackers@lists.postgresql.org; Wed, 19 Dec 2018 08:39:53 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gZXOQ-0000Js-Be for pgsql-hackers@postgresql.org; Wed, 19 Dec 2018 08:39:52 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id EE41521FEE; Wed, 19 Dec 2018 03:39:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 19 Dec 2018 03:39:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:subject:message-id:mime-version:content-type; s= fm3; bh=lOR5wYMCGqz3PwiueE6jP1dkGE6j6CQlhxy5/CBg+h0=; b=laBwnvAx nsTfX87obrK4CXFSK2x+akeK5Dbv5g/hQjYG9M6PYAlFtQdDpoImIP2Ea2GZyS13 ksXw6gQMoZNjFJzPyziP9kaYvkCOu9O+mlSSsXjNbBFOlbPGgDJQgkZ3wdLI5d5s kwJEI071BA+zD20xgYA/piwNs5bQagIv++jnzjgs4ue+nCHae86PO3wU+2p2tIU7 mnFohMEK3D9+wG/ttQTAevCBhHHcsbtWza2fXOylYZAU3shmwTg0l+f+vJpZcL0A l0bA8T7o+efsCTMU5oG6z+zifAvVi6htPURdX7YuD8ic6j/cfUMDmgzmPBrvJRNS alAv9pwUy8wG9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=lOR5wYMCGqz3PwiueE6jP1dkGE6j6 CQlhxy5/CBg+h0=; b=qo5W7kSs4T8NTFdQ80oJM3ccc0EdqxbniapZKfS/jvKTx baGi5JuQa+QUWOzSxjjls7Atj5Y7sYia4T4pAMJF/+PzYF+6jj7jnuNz1K2uMF+J WwomQYaHDLsad/0CgLZwhUBdrgF2zu7NBnITMDsqSwi7+qKSGG7Zq18bimENllrW yOSJz4XdhZN0GXeINGUAIpJjbakdyPWzxGnD2QSsi1WfzkQ6pFtFjdTzsCVmE0Q/ OK9ZlxsIaePHMs918f66i0yUyw1wBMYaFre/qznGCGmzJdj1PNj+f6Qj2jlgebqc C2eacLLVOp62dzInimSH+FaHtVW/EHFGOw4ZMKAGw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudeiledgledvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkgg gtugesthdtredttddtvdenucfhrhhomheptehnughrvghsucfhrhgvuhhnugcuoegrnhgu rhgvshesrghnrghrrgiivghlrdguvgeqnecukfhppeelkedrvddutddrudegtddrudejud enucfrrghrrghmpehmrghilhhfrhhomheprghnughrvghssegrnhgrrhgriigvlhdruggv necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E8BFE405D; Wed, 19 Dec 2018 03:39:48 -0500 (EST) Date: Wed, 19 Dec 2018 00:39:45 -0800 From: Andres Freund To: pgsql-hackers@postgresql.org, Amit Kapila , Robert Haas Subject: Why are we PageInit'ing buffers in RelationAddExtraBlocks()? Message-ID: <20181219083945.6khtgm36mivonhva@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, The zheap patchset, even after being based on pluggable storage, currently has the following condition in RelationAddExtraBlocks(): if (RelationStorageIsZHeap(relation)) { Assert(BufferGetBlockNumber(buffer) != ZHEAP_METAPAGE); ZheapInitPage(page, BufferGetPageSize(buffer)); freespace = PageGetZHeapFreeSpace(page); } else { PageInit(page, BufferGetPageSize(buffer), 0); freespace = PageGetHeapFreeSpace(page); } I.e. it initializes the page differently when zheap is used versus heap. Thinking about whether it's worth to allow to extend that function in an extensible manner made me wonder: Is it actually a good idea to initialize the page at that point, including marking it dirty? As far as I can tell that that has several downsides: - Dirtying the buffer for initialization will cause potentially superfluous IO, with no interesting data in the write except for a newly initialized page. - As there's no sort of interlock, it's entirely possible that, after a crash, the blocks will come up empty, but with the FSM returning it as as empty, so that path would be good to support anyway. - It adds heap specific code to a routine that otherwise could be generic for different table access methods It seems to me, this could be optimized by *not* initializing the page, and having a PageIsNew(), check at the places that check whether the page is new, and initialize it in that case. Right now we'll just ignore such pages when we encounter them (e.g. after a crash) until vacuum initializes them. But given that we've accepted that we'll potentially create empty pages anyway, I don't see what advantages that provides? The warnings emitted by vacuum are pretty scary, and can happen in a lot of legitimate cases, so removing them seems like a good idea anyway. I'm pretty tired, so I might be missing something large and obvious here. Greetings, Andres Freund