Re: pg_stat_statements and "IN" conditions
От | Yasuo Honda |
---|---|
Тема | Re: pg_stat_statements and "IN" conditions |
Дата | |
Msg-id | CAKmOUTkbC4oEBxZAP5=d30AcxjYHte0b+7JpGVNeB217erwa6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_statements and "IN" conditions (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: pg_stat_statements and "IN" conditions
|
Список | pgsql-hackers |
Thanks for the useful info. Ruby on Rails uses bigint as a default data type for the primary key and prepared statements have been enabled by default for PostgreSQL. I'm looking forward to these current patches being merged as a first step and future versions of pg_stat_statements will support normalizing bigint and prepared statements. On Wed, Mar 27, 2024 at 6:00 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote: > It's a similar case: the column is defined as bigint, thus PostgreSQL > has to wrap every constant expression in a function expression that > converts its type to bigint. The current patch version doesn't try to > reduce a FuncExpr into Const (event if the wrapped value is a Const), > thus this array is not getting merged. If you replace bigint with an > int, no type conversion would be required and merging logic will kick > in. > > Again, the original version of the patch was able to handle this case, > but it was stripped away to make the patch smaller in hope of moving > forward. Anyway, thanks for reminding about how annoying the current > handling of constant arrays can look like in practice!
В списке pgsql-hackers по дате отправления: