MIME-Version: 1.0
References: 
 <CAP53PkzYZ8YxH0o+Garw9fWdFRoEtmQKT09-q=2RVMW8uVS5Nw@mail.gmail.com>
 <CAA5RZ0tu-Si5MaaFMiVq+SONBv+fPPPwhtb65dHoO75Pfs8BEg@mail.gmail.com>
In-Reply-To: 
 <CAA5RZ0tu-Si5MaaFMiVq+SONBv+fPPPwhtb65dHoO75Pfs8BEg@mail.gmail.com>
From: Lukas Fittl <lukas@fittl.com>
Date: Wed, 25 Mar 2026 11:49:37 -0700
Message-ID: 
 <CAP53Pkyww5e433ssHzB0-=D8aNLAW3MEWW-71sc1P5gT8aCYvA@mail.gmail.com>
Subject: Re: pg_stat_statements: Add gc_count and query_file_size to pgss_info
To: Sami Imseih <samimseih@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAP53Pkyww5e433ssHzB0-%3DD8aNLAW3MEWW-71sc1P5gT8aCYvA%40mail.gmail.com>
Precedence: bulk

Hi Sami,

On Sun, Mar 1, 2026 at 7:44=E2=80=AFAM Sami Imseih <samimseih@gmail.com> wr=
ote:
> I do agree that having such additional information, with proper
> documentation, is a good idea. However, I do wonder if we should hold
> off on adding any of this info in 19 because of the point you make
> below, which could completely change the information we need to
> expose. Adding this information in 19 and then removing it for 20 may
> not be worthwhile.

Yeah, I suspect you're right - I'll mark this as returned with feedback for=
 now.

> > I've had a patch to improve this prepared for a previous cycle, but
> > wasn't sure it was still needed because of the discussion re: keeping
> > query texts in shared memory. But since it looks like that won't
> > change for 19 (though I'm hoping to contribute more to improving that
> > in the PG 20 cycle), see attached for consideration.
>
> 19 has 4ba012a8ed, which allows us to serialize and deserialize query
> texts stored in, for example, DSA, with a dsa_pointer tracked by the
> entry of a custom stats kind. I was also planning on continuing this
> work for 20, and getting 4ba012a8ed was an important prerequisite for
> this.

Yup, makes sense - I think 4ba012a8ed is a foundational piece to make
progress on this in 20.

I've also been wondering if we should prototype a new
pg_stat_statements module separately (e.g. in a GitHub repo,
"pg_stat_statements_next" or something), just to allow quicker
iteration and allow easier testing of a pure in-memory approach,
before bringing it to the discussion table for -hackers later in the
PG20 cycle.


Thanks,
Lukas

--
Lukas Fittl