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.94.2) (envelope-from ) id 1uM7yt-003DRX-QH for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Jun 2025 16:25:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uM7yq-00BAvx-7w for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Jun 2025 16:25:44 +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.94.2) (envelope-from ) id 1uM7yp-00BAvp-Uc for pgsql-hackers@lists.postgresql.org; Mon, 02 Jun 2025 16:25:43 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uM7ym-0003zP-2E for pgsql-hackers@postgresql.org; Mon, 02 Jun 2025 16:25:43 +0000 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-ad56829fabdso719684366b.1 for ; Mon, 02 Jun 2025 09:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748881540; x=1749486340; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0gTNfkr59PlmnGfTuKWHy6LB69S94+JJOY0/uHqo34I=; b=Pgc5rbG2awPUcnsN9DylTwK0SELfGAiG6f9wTxErHlNdninwkSjwU1oIgKc+15N01W J+g9VkAUzJiS9Wkj1oAm2k8KXI0T9BN5N9ejLYT71wUTFwB77aaqsP5Qc1V+N23lHLYH b31j47YINnq3AQih7riIghZDOBqjqOzgtlw+4E/1xSUpv1AIhzN3zkd9l6Yt1mZvFhAs ACahLcr3gbarVty0A0+6FnCtHJVjfHyRDvNlF42pTMWaaI0nfep28VoHDHCVBDtR22hh OimHwHXN0+ndKgDIqv8SZwu9MNgF7XyUBjQW19KuMRIYd5JHI6RdF3WDLIKjNRLb8Uc6 8qTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748881540; x=1749486340; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0gTNfkr59PlmnGfTuKWHy6LB69S94+JJOY0/uHqo34I=; b=kIaLFwGU5V4p9Yb0wskHdEvAgeMycIDMVzeTSvzh1a88wLY3ryOv7kY5jxWn4SNyKO Bqpnjad+RmLRsQo4g2QQqtYXso6IABvEg0xyGuMfrwXhFXtU7DLXDTYRNxmPeexlydZ5 uqL6ZI795mWfrYmJ2mtoSJ44RNFfw0iE20lv2dc0Z0oJkslPlSFX4RErjEPzTXzFQF+/ HjzlhsLp/Ejh1TIvhuyL30mDUcXk1grE4qjYrfowNMFXjI4+J++EBASqbE/6yQKCDLjM gIiaxu0RkW5K3U3XtvzgwoJ/wfQ9nkQ9cNMT+3DQx1GVqkujRn7RFO9YelxGd/XO17FF DKJw== X-Forwarded-Encrypted: i=1; AJvYcCW9mnJ6Mf0gZQnUuvaqFN1CEq02NC3VOQE25O5Gv+u+OCJovm99m/e2lK/IvbbVmwGIXfNFFR7VsmzzYIGf@postgresql.org X-Gm-Message-State: AOJu0Yw0Ki/tbpxxyG3+vPNpI9NUyiVn3Pk2Ime9YE7l8ccq/2vs12DH ysyjI7VZoXV/Ij8Nu3dbyh9IA5KsEPQ1fTH8FfMPbeVwIx4LFpnUdPPoYJOOfCxMYXu2BFaEIkE xCKG0wNFEAIuWj86Y434Vw/OuMQONh10= X-Gm-Gg: ASbGnctSGrVhr43UsSzs9gBMpc2EfOLABHZ516LMeKawOPtMprjqX2XGje4BXAEO1Hp NmZ1RoqvhPZve/KDCkzrRbIZclrywQvUrBF62GbjaPQwFpf7cC8xxb1uub46oGtJ1fDERGcPFcS JlAJX//H7DGJ4aNG7g5rFdc07/FNnmWSOviET9e7DEG/M= X-Google-Smtp-Source: AGHT+IHIdhTnCjrrjh51G6w7BQwQz2VdHVrLbWSH9TEsgukiA/aN19M6ItJIlj3wzNzCSCzZXyaA+xbnB8bO+5Jo/rI= X-Received: by 2002:a17:906:dc8d:b0:ad2:3f1f:7974 with SMTP id a640c23a62f3a-adb493aba1dmr900332866b.10.1748881540128; Mon, 02 Jun 2025 09:25:40 -0700 (PDT) MIME-Version: 1.0 References: <86f76aa5-1ab5-4e2e-9b15-405051852a2a@postgrespro.ru> <1e81a0a1-a63b-48fb-905a-d6495f89ab73@postgrespro.ru> <0b4eefc7-4c38-4caa-b2ca-a4c75dd7dd12@postgrespro.ru> <333c2306-c401-4959-9f0c-a44c670a11a9@postgrespro.ru> <513f0188-b093-4cc8-98cf-4c324570d525@postgrespro.ru> <47a7b784-5218-43f2-96e3-65f9a729c5a5@tantorlabs.com> <5583261b-eede-4341-b3b1-91650fefc1cf@postgrespro.ru> <2a04ad18-5572-4633-848b-eb57209e7ac0@postgrespro.ru> <2f48399f-2959-4483-938f-64edb863ca76@postgrespro.ru> In-Reply-To: <2f48399f-2959-4483-938f-64edb863ca76@postgrespro.ru> From: Alexander Korotkov Date: Mon, 2 Jun 2025 19:25:28 +0300 X-Gm-Features: AX0GCFvYxFsLQDTbvQioEWRHs5Q0zpkftO8Kk3EwajzAkqRtvRzK607ch0syWbk Message-ID: Subject: Re: Vacuum statistics To: Alena Rybakina Cc: Amit Kapila , pgsql-hackers , Jim Nasby , Bertrand Drouvot , Ilia Evdokimov , Kirill Reshke , Andrei Zubkov , Masahiko Sawada , Melanie Plageman , jian he , a.lepikhov@postgrespro.ru, Sami Imseih , vignesh C Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, May 13, 2025 at 12:49=E2=80=AFPM Alena Rybakina wrote: > On 12.05.2025 08:30, Amit Kapila wrote: > > On Fri, May 9, 2025 at 5:34=E2=80=AFPM Alena Rybakina wrote: > >> I did a rebase and finished the part with storing statistics separatel= y from the relation statistics - now it is possible to disable the collecti= on of statistics for relationsh using gucs and > >> this allows us to solve the problem with the memory consumed. > >> > > I think this patch is trying to collect data similar to what we do for > > pg_stat_statements for SQL statements. So, can't we follow a similar > > idea such that these additional statistics will be collected once some > > external module like pg_stat_statements is enabled? That module should > > be responsible for accumulating and resetting the data, so we won't > > have this memory consumption issue. > The idea is good, it will require one hook for the pgstat_report_vacuum > function, the extvac_stats_start and extvac_stats_end functions can be > run if the extension is loaded, so as not to add more hooks. +1 Nice idea of a hook. Given the volume of the patch, it might be a good idea to keep this as an extension. > But I see a problem here with tracking deleted objects for which > statistics are no longer needed. There are two solutions to this and I > don't like both of them, to be honest. > The first way is to add a background process that will go through the > table with saved statistics and check whether the relation or the > database are relevant now or not and if not, then > delete the vacuum statistics information for it. This may be > resource-intensive. The second way is to add hooks for deleting the > database and relationships (functions dropdb, index_drop, > heap_drop_with_catalog). Can we workaround this with object_access_hook? ------ Regards, Alexander Korotkov Supabase