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 по дате отправления: