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.92) (envelope-from ) id 1j7VLf-0005bt-7K for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Feb 2020 02:25: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 1j7VLd-0002Np-2E for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Feb 2020 02:25:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j7VLc-0002Nh-M1 for pgsql-hackers@lists.postgresql.org; Fri, 28 Feb 2020 02:25:52 +0000 Received: from mail-qv1-xf44.google.com ([2607:f8b0:4864:20::f44]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j7VLZ-0007Oo-8p for pgsql-hackers@lists.postgresql.org; Fri, 28 Feb 2020 02:25:51 +0000 Received: by mail-qv1-xf44.google.com with SMTP id p2so657279qvo.10 for ; Thu, 27 Feb 2020 18:25:49 -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=80o4vlvgQj5ubPrnYWgKGoeAikAi35Ew0uh6GMb9Plc=; b=p3TAALTz5XJsEQxhUWKrZFQqCpbttujwOp0cd6UL9BRqfSSezXGPc1+Qgh+xyFJ/En 7f/jCtRqa+isNu5aWI/bY7C8qrlabXMl7EzIZ9kZ7BvfTH7GE96HJeUd3V1ZMB+0acnc erEZ4n7nZVq8e3INF+TASQPWre8wQBGgF2GCCknKCHyF29oz7+5XjbTpGaVUPEueHzrJ S1yLns7QsLP9Ly0BKOqYFoV0u54iDOhk6WFp3Da6t08t+RGDzAuJY0nebN6h/e9pkXrF gdgBGCHBp8ysJ84qmEkvowhzOLbcqmSWpEn/CNj2asXWBe48O15g5LPf8yXnCeMNrkeD Cojg== 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=80o4vlvgQj5ubPrnYWgKGoeAikAi35Ew0uh6GMb9Plc=; b=d9E4CT1DkI28plp+fox00A+zQMldKupqnd1u+moe0IcRoBnWfMrjwBBJShDovxuxfH vhrbG50bF8AjaDVKSq82HjQeJCYN/i51DP060rbb3RZCQnebf3hdQ9C07f1FPsk0FsKa XCEfSx9rH8b3bQ3afqmmjW3Wk5jJJ1SjFO96mkyeid+6vtz1nH4PvGE/Fph7ykmaLFGI sWGhEIriLb2iHrat1WKpvs2CJFZplIDi2eV9i2Gk4kT15GGZ/jGF1ceBKjCk9yDc9xqv Im6oxby8suZ84euNCke45PlN8lI6FfSyr8OmSvQOwpgM+5R5HEH/zUPsxqHatv2wVKW6 6YQQ== X-Gm-Message-State: APjAAAUUonq8h0Sg+wLlkSwTAqV4tHH+xrpgr9ALsWzVo7z5bib1gAkd QNJSZp7RNpFyfRp6yKsgLoH6VQ== X-Google-Smtp-Source: APXvYqy/iDZWdFDiCzLagEYeDbkL5m0SbQKAauXGtHww/lf9yElGuRq4eFtewo8ee9Coq1oHNc6HVw== X-Received: by 2002:ad4:554b:: with SMTP id v11mr2001115qvy.0.1582856748320; Thu, 27 Feb 2020 18:25:48 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([201.186.208.119]) by smtp.gmail.com with ESMTPSA id j17sm4192082qke.69.2020.02.27.18.25.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2020 18:25:47 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id AF3E7300651; Thu, 27 Feb 2020 23:25:45 -0300 (-03) Date: Thu, 27 Feb 2020 23:25:45 -0300 From: Alvaro Herrera To: yuzuko Cc: Amit Langote , Masahiko Sawada , Laurenz Albe , PostgreSQL Hackers , Greg Stark Subject: Re: Autovacuum on partitioned table Message-ID: <20200228022545.GA19686@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello Yuzuko, > + * Report ANALYZE to the stats collector, too. If the table is a > + * partition, report changes_since_analyze of its parent because > + * autovacuum process for partitioned tables needs it. Reset the > + * changes_since_analyze counter only if we analyzed all columns; > + * otherwise, there is still work for auto-analyze to do. > */ > - if (!inh) > - pgstat_report_analyze(onerel, totalrows, totaldeadrows, > - (va_cols == NIL)); > + if (!inh || onerel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE) > + pgstat_report_analyze(onerel, totalrows, totaldeadrows, > + (va_cols == NIL)); Hmm, I think the comment has a bug: it says "report ... of its parent" but the report is of the same rel. (The pgstat_report_analyze line is mis-indented also). > /* > + * If the relation is a partitioned table, we must add up children's > + * reltuples. > + */ > + if (classForm->relkind == RELKIND_PARTITIONED_TABLE) > + { > + List *children; > + ListCell *lc; > + > + reltuples = 0; > + > + /* Find all members of inheritance set taking AccessShareLock */ > + children = find_all_inheritors(relid, AccessShareLock, NULL); > + > + foreach(lc, children) > + { > + Oid childOID = lfirst_oid(lc); > + HeapTuple childtuple; > + Form_pg_class childclass; > + > + /* Ignore the parent table */ > + if (childOID == relid) > + continue; I think this loop counts partitioned partitions multiple times, because we add up reltuples for all levels, no? (If I'm wrong, that is, if a partitioned rel does not have reltuples, then why skip the parent?) > + /* > + * If the table is a leaf partition, tell the stats collector its parent's > + * changes_since_analyze for auto analyze > + */ > + if (IsAutoVacuumWorkerProcess() && > + rel->rd_rel->relispartition && > + !(rel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)) I'm not sure I understand why we do this only on autovac. Why not all analyzes? > + { > + Oid parentoid; > + Relation parentrel; > + PgStat_StatDBEntry *dbentry; > + PgStat_StatTabEntry *tabentry; > + > + /* Get its parent table's Oid and relation */ > + parentoid = get_partition_parent(RelationGetRelid(rel)); > + parentrel = table_open(parentoid, AccessShareLock); Climbing up the partitioning hierarchy acquiring locks on ancestor relations opens up for deadlocks. It's better to avoid that. (As a test, you could try what happens if you lock the topmost relation with access-exclusive and leave a transaction open, then have autoanalyze run). At the same time, I wonder if it's sensible to move one level up here, and also have pgstat_report_partanalyze move more levels up. > + * pgstat_report_partanalyze() - > + * > + * Tell the collector about the parent table of which partition just analyzed. > + * > + * Caller must provide a child's changes_since_analyze as a parents. I'm not sure what the last line is trying to say. Thanks, -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services