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 1vgQQw-00CLYU-1C for pgsql-general@arkaria.postgresql.org; Thu, 15 Jan 2026 16:42:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vgQQv-000Yr4-1j for pgsql-general@arkaria.postgresql.org; Thu, 15 Jan 2026 16:42:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vgQQv-000Yqu-0C for pgsql-general@lists.postgresql.org; Thu, 15 Jan 2026 16:42:53 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vgQQs-000atC-2W for pgsql-general@postgresql.org; Thu, 15 Jan 2026 16:42:52 +0000 Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-59b679cff1fso1023793e87.0 for ; Thu, 15 Jan 2026 08:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768495370; x=1769100170; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=SE1svS9J/B0QFm5mkUZe6t/9C4sVYQemn+zMuKGfiPY=; b=lBY+0Y35mdcwVZA5SPoUnZWuVhV13aFXOVtmtzK6UY1jBp9f9xnAZJZ8VkT7zNIZo4 +NRCtzSk4w5nVgKzUL0H2e2I04pjY2aRCtSs8tutYihqDYqyVKRjQ5bB/NBpo0KaJog+ jMAKNFkdo8c7xeAN97/ZpOMgMKXREPAWE9xDfaiWdiasdmrGuVvR6YjXHm8qMbdhdoWY CG5wqy+6Vu37dCmEVGyw53nJOIYvOV9Dkwy+qsx0wIUwoOFTX9iqs/sxgTvpG6OOEjOh /9CA2c/bCmYQ2Y0TEvnrBalTazCTK2+JBiSpS5vkP6m2JnbpaJ/h6EFutRm2WtXK7faq KZQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768495370; x=1769100170; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SE1svS9J/B0QFm5mkUZe6t/9C4sVYQemn+zMuKGfiPY=; b=Ky1Rr8oGxE0EaKMlORvXtiq3A5WInqmaGt1K5ouieRZlMDZ2n+b369XKhHIxYBuo4F uIZ0bV5mkBvo3+3OubsJrfPcZlaaJQ929QykZKGwSAbAT1fcTT48BXGlNCt1eSdqFQDZ qAGyk/C9JZbtA7DyJNG/SipzhwN6rJJlrSFmgB0QTjNuqWLGl4bWpTTL6qkGi2wtGnmx 7mG+FnF75EosxT2FG3lbex3kTIUrtmhi8BJ0x+FHc9hasJ6cuFR+R3i4CRVYn2J18BtA HYqbLaFOIMOZc02t5YqtlVmEC0ar7vV2VYyNviuXIzXewrKcE8mYcYHmxV+qeNxIFAUM /rQg== X-Gm-Message-State: AOJu0YyY1McnZrA1X+AGOeXMpXR8VT4MLMp1ypOzoaIZuzY+k/p2OsTH XxYRaAAADaTy926r2OulRDq6EIWY13rF1duaLFT6HZ81tLsZHBwzz8VrVRdP1OnNXupD+dZMog1 iT7pANaEFQh14A/GmbH7+n0d0yOUxIwAmCU8s X-Gm-Gg: AY/fxX4iaOsDG8Byq+VsxrRNIO3uDJBw4pqfVXm2U8HZXR9rFjS8xMpIBreuXbx0Zxe wHQmBS4RW2oseCYb9xT0X2q0FxpoCsIE876IPyGFty9V/2TcruMHnTGFQkVAwA5e7VXW9Sa0p3E qUjwhigo5js7vENsjyHyLe4ENlepatEtEbYuiexCCGhkZarSLmBwXYxtz03vW6wJkz9E0X4RgJA 7lwrteTvXIxu/gEpCHMAqBRXyKQW2lTpF3+1cRUiMYVN5ynPWi/m1TKyw7kRnR4IGW6bYVT X-Received: by 2002:a05:6512:15a5:b0:59b:845e:b505 with SMTP id 2adb3069b0e04-59baeef70aemr55121e87.31.1768495369251; Thu, 15 Jan 2026 08:42:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: pramod gupta Date: Thu, 15 Jan 2026 22:12:36 +0530 X-Gm-Features: AZwV_Qgz6r-PGoGS2zwVtHoVPWQi0dHB7MUCXVZsKzF6xcb8eW6_6XR3vrj4s7M Message-ID: Subject: Re: How did VACUUM ANALYZE reclaim large TOAST bloat at disk level in PostgreSQL 16? To: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="000000000000456ef606486fea56" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000456ef606486fea56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Everyone, I am encountering the following error while using the *pg_ai_query* extension. *test=3D# SELECT generate_query('show recent orders', null, 'gemini');ERROR= : Query generation failed: No API key available for gemini provider. Please provide API key as parameter or configure it in ~/.pg_ai.config.test=3D#test=3D# SELECT generate_query('show recent orders'= , null, 'google_ai_studio');ERROR: Query generation failed: API key required. Pass as parameter or set OpenAI, Anthropic, or Gemini API key in ~/.pg_ai.config.test=3D#* have verified all required permissions and confirmed that the configuration is correctly placed; however, I continue to receive the above error when using the *pg_ai.config* file. If I execute the query by explicitly passing the API key, it works as expected: *select generate_query('I want to count the rows in orders tables','MYAPIKEY','gemini');* This works perfectly. I would appreciate guidance on how to configure this so that the API key does not need to be passed explicitly in the query. Please let me know if there is any alternative configuration or recommended approach to achieve this. Thanks in advance. Pramod Gupta ---------------------------------------------------------------------------= ------------------------------------------------------------ On Mon, Dec 29, 2025 at 9:23=E2=80=AFPM pramod gupta wrote: > Hello Everyone, > > We have a table with a total size of ~628 GB, out of which ~601 GB was > TOAST data. > After running VACUUM ANALYZE on a weekly basis, the table size reduced > significantly to ~109 GB, indicating a large amount of bloat removal. > > I would like to understand: > > How was VACUUM ANALYZE able to reclaim such a large amount of space, > especially for TOAST data? > > Under what conditions does PostgreSQL reclaim disk space without requirin= g > VACUUM FULL or CLUSTER? > > Is this behavior expected in PostgreSQL 16, particularly for heavily > updated or deleted TOASTed columns? > > Any insights or documentation references would be greatly appreciated. > > PostgreSQL version: 16 > > Thanks in advance. > Pramod Gupta > --000000000000456ef606486fea56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Everyone,

I am encountering the following error while using the pg_ai_quer= y extension.

test=3D# SELECT generate_query('show rec= ent orders', null, 'gemini');
ERROR: =C2=A0Query generation = failed: No API key available for gemini provider. Please provide API key as= parameter or configure it in ~/.pg_ai.config.
test=3D#
test=3D# SELE= CT generate_query('show recent orders', null, 'google_ai_studio= ');
ERROR: =C2=A0Query generation failed: API key required. Pass as = parameter or set OpenAI, Anthropic, or Gemini API key in ~/.pg_ai.config.test=3D#

=C2=A0have verified all required permissions and confi= rmed that the configuration is correctly placed; however, I continue to rec= eive the above error when using the pg_ai.config file.

=

If I execute the query by explicitly passing the API key, it works a= s expected:

select generate_query('I want to count the rows in= orders tables','MYAPIKEY','gemini');


Thi= s works perfectly. I would appreciate guidance on how to configure this so = that the API key does not need to be passed explicitly in the query. Please= let me know if there is any alternative configuration or recommended appro= ach to achieve this.

Thanks in advance.
Pramod= Gupta
----------------------------------------------= ---------------------------------------------------------------------------= --------------

On Mon, Dec 29, 2025 at 9:23=E2=80=AFPM= pramod gupta <mail2sony2010@= gmail.com> wrote:
Hello Everyone,

We have a table with a t= otal size of ~628 GB, out of which ~601 GB was TOAST data.
After running= VACUUM ANALYZE on a weekly basis, the table size reduced significantly to = ~109 GB, indicating a large amount of bloat removal.

I would like to= understand:

How was VACUUM ANALYZE able to reclaim such a large amo= unt of space, especially for TOAST data?

Under what conditions does = PostgreSQL reclaim disk space without requiring VACUUM FULL or CLUSTER?
=
Is this behavior expected in PostgreSQL 16, particularly for heavily up= dated or deleted TOASTed columns?

Any insights or documentation refe= rences would be greatly appreciated.

PostgreSQL version: 16

T= hanks in advance.
Pramod Gupta
--000000000000456ef606486fea56--