Re: Slow query after upgrades
От | Tom Duffey |
---|---|
Тема | Re: Slow query after upgrades |
Дата | |
Msg-id | 7D15C939-3764-4D45-9070-352742142269@techbydesign.com обсуждение исходный текст |
Ответ на | Re: Slow query after upgrades (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Slow query after upgrades
|
Список | pgsql-jdbc |
On Dec 13, 2007, at 7:03 PM, Tom Lane wrote: > Oliver Jowett <oliver@opencloud.com> writes: >> The JDBC driver is using an unnamed statement in this case, shouldn't >> the planner end up using index selectivity estimates based on the >> actual >> parameter values? > > If he's using a recent enough backend, it should. > >> From the explain output that just came through it looks like a type >> mismatch problem on the timestamp parameter. > > Yeah, no question. Implicit casts to text strike again :-(. He was > probably getting the wrong answers, not only a slow query. What do you think about adding type information to the log? Something like: DETAIL: parameters: $1 = '21001'::integer, $2 = '2007-12-11 22:22:45'::text or similar would have revealed the source of my problem earlier. Tom
В списке pgsql-jdbc по дате отправления: