Re: pg_stat_statements and "IN" conditions
От | Dmitry Dolgov |
---|---|
Тема | Re: pg_stat_statements and "IN" conditions |
Дата | |
Msg-id | 20210616140212.kt3n5wi3alfz5i5d@localhost обсуждение исходный текст |
Ответ на | Re: pg_stat_statements and "IN" conditions (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: pg_stat_statements and "IN" conditions
|
Список | pgsql-hackers |
> On Tue, Jun 15, 2021 at 05:18:50PM +0200, Dmitry Dolgov wrote: > > On Thu, Mar 18, 2021 at 04:50:02PM +0100, Dmitry Dolgov wrote: > > > On Thu, Mar 18, 2021 at 09:38:09AM -0400, David Steele wrote: > > > On 1/5/21 10:51 AM, Zhihong Yu wrote: > > > > > > > > + int lastExprLenght = 0; > > > > > > > > Did you mean to name the variable lastExprLenghth ? > > > > > > > > w.r.t. extracting to helper method, the second and third > > > > if (currentExprIdx == pgss_merge_threshold - 1) blocks are similar. > > > > It is up to you whether to create the helper method. > > > > I am fine with the current formation. > > > > > > Dmitry, thoughts on this review? > > > > Oh, right. lastExprLenghth is obviously a typo, and as we agreed that > > the helper is not strictly necessary I wanted to wait a bit hoping for > > more feedback and eventually to post an accumulated patch. Doesn't make > > sense to post another version only to fix one typo :) > > Hi, > > 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.
Вложения
В списке pgsql-hackers по дате отправления: