Re: Bug in pg_stat_statements
| От | Sami Imseih |
|---|---|
| Тема | Re: Bug in pg_stat_statements |
| Дата | |
| Msg-id | CAA5RZ0sR-mhLdzuXrVVLcouAP4sf1qNnzBC5qq10TVbsTviROg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Bug in pg_stat_statements (Dmitry Dolgov <9erthalion6@gmail.com>) |
| Ответы |
Re: Bug in pg_stat_statements
|
| Список | pgsql-hackers |
> This sort of short cut the verification for duplicated constants. Having said > that it seems that another solution would be to check for duplicated constants > in fill_in_constant_lengths just before skipping squashed constants and reset > the length if needed. Hi, yes, I was not convinced my initial idea is good, and I ended up finding another case that still breaks: ``` SELECT (ROW(ARRAY[1, 2], ARRAY[1, 2, 3])).*; ``` Here we have multiple squashable lists, and simply checking that the location we are trying to record != the last location does not work. Also, checking that the location we are trying to record is ahead of the last location also does not work because the locations of squashable lists in the predicate will be recorded first. So, we can't rely on the location we want to record being higher than previous locations. For example: ``` SELECT (ROW(ARRAY[1, 2], ARRAY[1, 2, 3])).* FROM t WHERE x IN (1, 2, 3); ``` > Having said > that it seems that another solution would be to check for duplicated constants > in fill_in_constant_length Yes, I started thinking along these lines as well, where we check for duplicates in fill_in_constant_length; or after jumbling, we de-duplicate locations if we have a squashable list, which is what I have attached with updated test cases. This means we do need to scan the locations one extra time during jumbling, but I don't see that as a problem. Maybe there is another better way? -- Sami Imseih Amazon Web Services (AWS)
Вложения
В списке pgsql-hackers по дате отправления: