> 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)
