Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dZy5r-0004Xf-RX for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Jul 2017 11:33:40 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dZy5r-0004Ib-E1 for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Jul 2017 11:33:39 +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 1dZy5p-0004G6-JM for pgsql-hackers@postgresql.org; Tue, 25 Jul 2017 11:33:37 +0000 Received: from mail-wr0-x233.google.com ([2a00:1450:400c:c0c::233]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dZy5l-0005qN-W9 for pgsql-hackers@postgresql.org; Tue, 25 Jul 2017 11:33:37 +0000 Received: by mail-wr0-x233.google.com with SMTP id v105so87490776wrb.0 for ; Tue, 25 Jul 2017 04:33:33 -0700 (PDT) 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; bh=bClMG1kYyYLG+4H6vLBTPW94P+IZwDRMddE8rr9Ji3g=; b=c96v7Bqx/rjpTZQa4XL/LASHpRMp2eXRwebGXclCC2ZEc4Mmmbbrc0SbremHatB8RW 8pQstkXYQOx8BqfvPlMFAYP8mX8U0llEpqn/3sfl/Jm0dyGNWejGhw0JQvuxtSLV9m3K qJ4iN1QEnEiD6HbQuyt6cePH403BtjyH0oVq6Z3sLIFMBrc0PGSEE1uJwvRm4ZTKkVpC q1gU/mpv/a++hc2HXu/dDFzIDaARaVLcnGDTL5AO0Oh5//lIodx5XwSvETipRCAtiuZr XqnQLqNlhYDabKHEHMQk5vsOZz785tkkrZ9d2asJYYy7rBGpRrHbOZpTEn1C1nDaryKn RiVQ== 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; bh=bClMG1kYyYLG+4H6vLBTPW94P+IZwDRMddE8rr9Ji3g=; b=b+U85hlGa8+ar2vexvtDk2OUSAiZleLb6P6K1KZTG9Utn1KO84vLcxp0Y35zfO40Qj RFVK3lr5qmbjR50qgiiynVrcceY968U+RgFZNSxo9aBFKor8gS2Nmr/h9mzjhpUL1cKm PAykvEw35TFiuj2REQIs91Fg5EAW2JxQyvvdaefq/CqDk30jdvosg8ST3rAlndo81bWS TZtY07qpW/M5oe/hc/8cKyH9nIpz8eVS9hazE1CzIFlYEGU1zVFF4f1KqKb8tq3RCFDO R1wHIvhSP/pVQa9is3nfkfkyuFjeHvY9bYAg5XeH8wf4UWTKLg/7g345zVSwOnJQxFyp cIFw== X-Gm-Message-State: AIVw112MdL4FN9PUXh8PbTsWgdWV2s7y2WUhe4pQl0HJpr8qYqXrPlOx s013H+8Z7KGbgPJAfc2Xn4K1Dzlmpv+Sbo0rRxtOH+iknx7kcgKM5o9zBDsNduixkXk9AN+rdyv kzGVYglXZ/EjGC9q4yIYx+IfWrKfnZC56pGXXsL+K8EjQAQTLvA4bGQjzB0CCxNNUYjZmZ43vT5 8= X-Received: by 10.223.139.216 with SMTP id w24mr6383450wra.206.1500982411890; Tue, 25 Jul 2017 04:33:31 -0700 (PDT) Received: from [10.137.2.17] (ip-89-177-46-65.net.upcbroadband.cz. [89.177.46.65]) by smtp.gmail.com with ESMTPSA id p19sm10860636wma.40.2017.07.25.04.33.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 04:33:30 -0700 (PDT) Subject: Re: VACUUM and ANALYZE disagreeing on what reltuples means To: Tom Lane Cc: pgsql-hackers@postgresql.org References: <16db4468-edfa-830a-f921-39a50498e77e@2ndquadrant.com> <19990.1500936945@sss.pgh.pa.us> From: Tomas Vondra Message-ID: <3d250597-384e-c5f4-7533-b513e366888f@2ndquadrant.com> Date: Tue, 25 Jul 2017 13:33:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Thunderbird/55.0 MIME-Version: 1.0 In-Reply-To: <19990.1500936945@sss.pgh.pa.us> Content-Type: multipart/mixed; boundary="------------B79A28F4D3677068163FFAF1" Content-Language: en-US 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 This is a multi-part message in MIME format. --------------B79A28F4D3677068163FFAF1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 7/25/17 12:55 AM, Tom Lane wrote: > Tomas Vondra writes: >> It seems to me that VACUUM and ANALYZE somewhat disagree on what >> exactly reltuples means. VACUUM seems to be thinking that reltuples >> = live + dead while ANALYZE apparently believes that reltuples = >> live > >> The question is - which of the reltuples definitions is the right >> one? I've always assumed that "reltuples = live + dead" but perhaps >> not? > > I think the planner basically assumes that reltuples is the live > tuple count, so maybe we'd better change VACUUM to get in step. > Attached is a patch that (I think) does just that. The disagreement was caused by VACUUM treating recently dead tuples as live, while ANALYZE treats both of those as dead. At first I was worried that this will negatively affect plans in the long-running transaction, as it will get underestimates (due to reltuples not including rows it can see). But that's a problem we already have anyway, you just need to run ANALYZE in the other session. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --------------B79A28F4D3677068163FFAF1 Content-Type: text/x-patch; name="vacuum-reltuples-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vacuum-reltuples-fix.patch" diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c index c5c194a..574ca70 100644 --- a/src/backend/commands/vacuumlazy.c +++ b/src/backend/commands/vacuumlazy.c @@ -1261,7 +1261,7 @@ lazy_scan_heap(Relation onerel, int options, LVRelStats *vacrelstats, vacrelstats->new_rel_tuples = vac_estimate_reltuples(onerel, false, nblocks, vacrelstats->tupcount_pages, - num_tuples); + num_tuples - nkeep); /* * Release any remaining pin on visibility map page. --------------B79A28F4D3677068163FFAF1 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers --------------B79A28F4D3677068163FFAF1--