>On Wed, Jun 16, 2021 at 04:02:12PM +0200, Dmitry Dolgov wrote: > > > I've prepared a new rebased version to deal with the new way of > > computing query id, but as always there is one tricky part. From what I > > understand, now an external module can provide custom implementation for > > query id computation algorithm. It seems natural to think this machinery > > could be used instead of patch in the thread, i.e. one could create a > > custom logic that will enable constants collapsing as needed, so that > > same queries with different number of constants in an array will be > > hashed into the same record. > > > > But there is a limitation in how such queries will be normalized > > afterwards — to reduce level of surprise it's necessary to display the > > fact that a certain query in fact had more constants that are showed in > > pgss record. Ideally LocationLen needs to carry some bits of information > > on what exactly could be skipped, and generate_normalized_query needs to > > understand that, both are not reachable for an external module with > > custom query id logic (without replicating significant part of the > > existing code). Hence, a new version of the patch. > > Forgot to mention a couple of people who already reviewed the patch.
And now for something completely different, here is a new patch version. It contains a small fix for one problem we've found during testing (one path code was incorrectly assuming find_const_walker results).
Hi,
bq. and at position further that specified threshold.
that specified threshold -> than specified threshold