> >> I see where you're coming from on that, but I don't think we can > >> remove anything here in practice: > > > > Yes. Not unless we want to rely on the parser to track the lengths in > > Const, which could be invasive, but I have not looked into it. > > Hmm. We may not want to get down to that, still that would be > cheaper than reprocessing the parsing of the query string twice.
Although unless an extension, at least pg_stat_statements, should not be doing this double work often, and if it is it is due to heavy churn on entries. > >> I still think it'd be reasonable for us to include > >> ComputeConstantLengths in core to complete the picture of what we're > >> doing with _jumbleElements and the length field already anyway. Its > >> basically a way to fully hydrate the partially filled out JumbleState > >> from the initial jumble. > > > > I fully agree, ComputeConstantLengths is an optional post-jumble-query step > > for a consumer that wishes to calculate the lengths. The length calculation > > is not unique to a plug-in, so in my mind the work it's doing is core > > jumbling functionality. > > Okay. I could fall into that for this release. Marking the > JumbleState as a const is the most important piece here. I do agree. > I'm +-0 regarding this routine, but I can also see your point about how it's > useful to give at least the option to extensions to have a > recomputation of the Const lengths, the same way as PGSS. What are > the extensions that would use that? https://github.com/search?q=fill_in_constant_lengths&type=code A few well-known extensions/tools out there based on a Github search. -- Sami
