Re: Cleaning up PREPARE query strings?

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Cleaning up PREPARE query strings?
Date: 2026-01-15 19:13:36
Message-ID: CAA5RZ0sHJ2D2vdhH4nnUVuZKfSqpaywPeP98C9-LkGKG2rPSYg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I only had a quick look at the code but unless I'm missing something it's
> mostly an oversight as I pass "new_query" to CreateCachedPlan() but still pass
> the original query string to pg_analyze_and_rewrite_varparams(). Using
> "new_query" there too should fix the problem?

That will be a fix, but that seems way too invasive for me. Not sure if it may
break other things.

> > I am thinking that storing the statement length and location in the entry
> > of prepared_queries may be the better option. Having that info, the
> > cleaned up query text can be generated on the fly whenever
> > pg_prepared_statement is called.
>
> I don't like this approach as it has more execution time overhead, but also
> doesn't fix at all the memory waste in the prepared statements cache.

ISTM that your proposal will actually use more memory because
pstate->p_sourcetext does not get free'd, but we must now allocate
space for a new "cleaned" query.

As far as execution overhead, this will only be paid when you query
pg_prepared_statement, and we can even optimize this a bit by only
cleaning once and reusing the results.

> FWIW I think that this should belong to pg_stat_statements testing, no the main
> regression tests. This would also ensure that we see consistent results in
> some other scenarios.

I agree.

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2026-01-15 19:45:46 Re: code contributions for 2025, WIP version
Previous Message Heikki Linnakangas 2026-01-15 19:11:54 Re: Fix possible 'unexpected data beyond EOF' on replica restart