> On Mar 28, 2026, at 2:09, Sami Imseih <samimseih@gmail.com> wrote:
> I agree that ComputeConstantLengths should be in core. This one is
> not a gray area IMO. The query jumble already records constant locations,
> but leaves the lengths unset. ComputeConstantLengths is just the
> completion of that work. There could be no other interpretation,
> unlike generate_normalized_query, of what the lengths should be.
This is an interesting remark. One problem with any patches presented yet is that we don’t attach the lengths as part
ofthe in-core query jumbling procedure: we plug the lengths later using the same structure as the query jumbling. It
seemsto me that this is half-baked overall. I think that we don’t want to pay the extra length computation in the core
queryjumbling at the end, then why does it make sense to include the lengths in the JumbleState structure at all?
Shouldn’twe use a different structure filled inside PGSS for this purpose rather than reuse the same thing for PGSS and
thein-core part (don’t have the code in front of me now).
--
Michael
