Re: Trouble with plan statistics for behaviour for query.
От | Maciek Sakrejda |
---|---|
Тема | Re: Trouble with plan statistics for behaviour for query. |
Дата | |
Msg-id | CAOtHd0Bh+LxwQy70wfr9khrKGbz+umZBQDXYOnLLee4ZJ9e9Pw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Trouble with plan statistics for behaviour for query. (Vitalii Tymchyshyn <tivv00@gmail.com>) |
Ответы |
Re: Trouble with plan statistics for behaviour for query.
Re: Trouble with plan statistics for behaviour for query. |
Список | pgsql-performance |
> If I am correct, JDBC uses named portal only on the 5th time you use > PreparedStatement (configurable). Before it uses unnamed thing that should > work as if you did embed the value. If this is due to the difference in parameter type information, this doesn't have anything to do with named portals. My guess is that the driver has one idea about parameter types (based on either the specific setTypeFoo call or the Java type of the parameter passed to setObject), and the server another (based on the type information of the CHANGEGROUP.ISSUEID column). Actually, I'm rather surprised to see 'real' there: if you're using setObject with a Long, I would imagine that turns into a bigint (which I believe the server knows how to coerce to numeric). Can you show us your JDBC code?
В списке pgsql-performance по дате отправления: