Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cKVrO-0004aQ-Co for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Dec 2016 19:50:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cKVrN-0004uF-Nz for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Dec 2016 19:50:33 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cKVpx-0003G5-KC for pgsql-hackers@postgresql.org; Fri, 23 Dec 2016 19:49:05 +0000 Received: from mail-qt0-x22f.google.com ([2607:f8b0:400d:c0d::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cKVpu-000051-Nw for pgsql-hackers@postgresql.org; Fri, 23 Dec 2016 19:49:04 +0000 Received: by mail-qt0-x22f.google.com with SMTP id d45so46705420qta.1 for ; Fri, 23 Dec 2016 11:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=4yObsf2o+nrdMJCg3jkG+rxc93hMHT5LY9AADps30jQ=; b=agf5G4tsGGlLHjzRlqfJbTE5/2cME+aSjOe0MgS144oBDEiCubTrJzxVQ2va0XcLWP DdXefXf9iXjkWfBh+kptu6OxYi9r++B73VcCDYYEm0NEH8Fuft/y9Vz2RbEZi61SpdxQ Z1378Ojmr3xuSaoDkA+zUwVspFnzFilYmhTe+YjZ/EByPywBH1j3UUIoV2AlfKgGN+06 HF8wIVRkP152daumSYXJDiYy8WhvK2/m9dBCqQLEi4DqPcghG7VkrFbKk+6cBwObuBwQ 0KJKsobQxaRJk0t2RZeYTgEfaTNrz2O0hF1UB7XLhClDeZqCOK8xK4FBybRxGL58E3/6 /J4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=4yObsf2o+nrdMJCg3jkG+rxc93hMHT5LY9AADps30jQ=; b=eH8ZraMYm4iw+N/cYzYBfKkOBnAncEiylLTm671JU1o+IkcPa/NR59Bxrtc5CFuXmj sQA03seAhgsUm4uH8lurlgUMNGB8EKkSTeMus3J/iYEDmw2E3Bl3ncPG1AJHejLJKRK/ GEQBw5vZgIlq6hNyq8tLZk+IaZee63MWQ4opsF6TPhMmaWf7z7p8o7Z594xNZysep9O+ OYYwJTOKrrIj3pUbhRFzgbDVgJUEqvQ5RUHImn+q2hVsBnYuaLcsM2YjA+n10D0ObHtY FbjsUj7vI3sGNSFOn9KE7iXWXRb/Q0DTUpIdS2wADryxg7eXNsIPx5MSrQT0aZjrYUT6 uUNw== X-Gm-Message-State: AIkVDXK4l+9MWjVI2hrwBLbuthKcx7YXFCZaBGA26OwUOtY/QH9V8kWt8cxic3UVlEvVVUzw X-Received: by 10.200.46.40 with SMTP id r37mr15422811qta.267.1482522541214; Fri, 23 Dec 2016 11:49:01 -0800 (PST) Received: from alvin.alvh.no-ip.org ([179.56.97.120]) by smtp.gmail.com with ESMTPSA id q62sm17462545qkb.46.2016.12.23.11.49.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Dec 2016 11:49:00 -0800 (PST) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 1F2CE1595; Fri, 23 Dec 2016 16:48:59 -0300 (CLST) Date: Fri, 23 Dec 2016 16:48:59 -0300 From: Alvaro Herrera To: Pavan Deolasee Cc: Haribabu Kommi , Tomas Vondra , pgsql-hackers Subject: Re: Patch: Write Amplification Reduction Method (WARM) Message-ID: <20161223194859.ryiopmds22zr5ts3@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20161223192245.hx4rbrxbrwtgwj6i@alvherre.pgsql> User-Agent: NeoMutt/20161104 (1.7.1) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Alvaro Herrera wrote: > With your WARM and my indirect indexes, plus the additions for for-key > locks, plus identity columns, there is no longer a real expectation that > we can exit early from the function. In your patch, as well as mine, > there is a semblance of optimization that tries to avoid computing the > updated_attrs output bitmapset if the pointer is not passed in, but it's > effectively pointless because the only interesting use case is from > ExecUpdate() which always activates the feature. Can we just agree to > drop that? I think the only case that gets worse is the path that does simple_heap_update, which is used for DDL. I would be very surprised if a change there is noticeable, when compared to the rest of the stuff that goes on for DDL commands. Now, after saying that, I think that a table with a very large number of columns is going to be affected by this. But we don't really need to compute the output bits for every single column -- we only care about those that are covered by some index. So we should pass an input bitmapset comprising all such columns, and the output bitmapset only considers those columns, and ignores columns not indexed. My patch for indirect indexes already does something similar (though it passes a bitmapset of columns indexed by indirect indexes only, so it needs a tweak there.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers