Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vkNh0-00EEkN-0e for pgsql-admin@arkaria.postgresql.org; Mon, 26 Jan 2026 14:35:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vkNgz-008KJa-0x for pgsql-admin@arkaria.postgresql.org; Mon, 26 Jan 2026 14:35:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vkNgy-008KJS-2b for pgsql-admin@lists.postgresql.org; Mon, 26 Jan 2026 14:35:49 +0000 Received: from forward502d.mail.yandex.net ([178.154.239.210]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vkNgw-00000000YR3-2sxr for pgsql-admin@lists.postgresql.org; Mon, 26 Jan 2026 14:35:48 +0000 Received: from mail-nwsmtp-smtp-production-main-77.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-77.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:9407:0:640:8fbc:0]) by forward502d.mail.yandex.net (Yandex) with ESMTPS id 9BB0EC1038; Mon, 26 Jan 2026 17:35:44 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-77.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id hZhP800G4eA0-PaEhrdbm; Mon, 26 Jan 2026 17:35:44 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1769438144; bh=yo5sPQ0YkBrNSRNAQhSvR2uS3tX1R/Q1zBT1JU8RX5I=; h=In-Reply-To:References:To:Subject:Message-ID:Date:From; b=vlYStons5IASMnoN0vgVRL2OeillyG99cUOu7fZMylICGErT1BG8KIKWJ0NNwVBK2 bXP5irHlgssHTd9IDRNVc0N3VHLbxVSMp6v3c31/x+w1fpRg4yrGbRN3Firu3VDc+N Km11A8sasAAnodhzQ67yUIbpPUPQcVaoyaSbommA= Authentication-Results: mail-nwsmtp-smtp-production-main-77.iva.yp-c.yandex.net; dkim=pass header.i=@ya.ru Content-Type: multipart/alternative; boundary="------------604KVak7W8GBVjrtV9HecBm0" Message-ID: Date: Mon, 26 Jan 2026 17:35:42 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: autoanalyze did not run To: Laurenz Albe , Pgsql-admin References: <0dce35ca-24fa-4234-99fe-071bd5725a32@ya.ru> Content-Language: ru, en-US From: =?UTF-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------604KVak7W8GBVjrtV9HecBm0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 26.01.2026 10:23, Laurenz Albe пишет: > On Mon, 2026-01-26 at 08:31 +0300, Олег Самойлов wrote: >> I try to investigate why autoanalyze did not run in time of our initial >> loading data. Yes, I know, running analyze manually is highly >> recommended in such case. But is must run automatically too. > You'd have to show more evidence that this is a bug, or provide a way > to reproduce the problem. I need to narrow my case, that why I need to know on what exactly depends (on what column) the launching the autoexplain. >> select relid::regclass, n_live_tup, n_tup_ins, n_tup_upd, >> n_mod_since_analyze from pg_stat_user_tables as s join pg_class as c on >> (s.relid=c.oid) where s.autoanalyze_count=0 and relkind='r' and >> n_live_tup>0 limit 1; >> -[ RECORD 1 ]-------+---------- >> relid               | addresses >> n_live_tup          | 13844405 >> n_tup_ins           | 0 >> n_tup_upd           | 0 >> n_mod_since_analyze | 0 >> >> PostgreSQL 17.7 (Debian 17.7-3.pgdg13+1) on x86_64-pc-linux-gnu, >> compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit (from PGDG) > Are you sure that you committed the transaction? I am very sure, thats why there are 13844347 rows in that table. By single copy. > Is "track_activities" set to "on"? I checked, yep. > Yours, > Laurenz Albe --------------604KVak7W8GBVjrtV9HecBm0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


26.01.2026 10:23, Laurenz Albe пишет:
On Mon, 2026-01-26 at 08:31 +0300, Олег Самойлов wrote:
I try to investigate why autoanalyze did not run in time of our initial 
loading data. Yes, I know, running analyze manually is highly 
recommended in such case. But is must run automatically too.
You'd have to show more evidence that this is a bug, or provide a way
to reproduce the problem.
I need to narrow my case, that why I need to know on what exactly depends (on what column) the launching the autoexplain.
select relid::regclass, n_live_tup, n_tup_ins, n_tup_upd, 
n_mod_since_analyze from pg_stat_user_tables as s join pg_class as c on 
(s.relid=c.oid) where s.autoanalyze_count=0 and relkind='r' and 
n_live_tup>0 limit 1;
-[ RECORD 1 ]-------+----------
relid               | addresses
n_live_tup          | 13844405
n_tup_ins           | 0
n_tup_upd           | 0
n_mod_since_analyze | 0

PostgreSQL 17.7 (Debian 17.7-3.pgdg13+1) on x86_64-pc-linux-gnu, 
compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit (from PGDG)
Are you sure that you committed the transaction?

I am very sure, thats why there are 13844347 rows in that table. By single copy.

Is "track_activities" set to "on"?

I checked, yep.

Yours,
Laurenz Albe
--------------604KVak7W8GBVjrtV9HecBm0--