Re: Slow query after upgrades
От | Tom Duffey |
---|---|
Тема | Re: Slow query after upgrades |
Дата | |
Msg-id | 62EFD840-6C75-4220-9CC3-77D35C76403F@techbydesign.com обсуждение исходный текст |
Ответ на | Re: Slow query after upgrades (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: Slow query after upgrades
|
Список | pgsql-jdbc |
On Dec 13, 2007, at 5:05 PM, Oliver Jowett wrote: > Tom Duffey wrote: > >> This makes a huge difference, thanks. However, is there anything I >> can do to help improve the performance of that query when using a >> newer protocol? > > We need to work out what is going wrong under the newer protocol > first, which unfortunately can be a bit tricky because psql doesn't > use the query protocol in the same way as the JDBC driver. > > Can you write a little JDBC app that runs the query with EXPLAIN > ANALYZE, setting parameters in the same way that your real app does, > and dump out the resultset it gets back? (which should be the > EXPLAIN results rather than the real data, IIRC) QUERY PLAN=Sort (cost=289075.73..289147.11 rows=28554 width=20) (actual time=141222.112..141222.294 rows=192 loops=1) QUERY PLAN= Sort Key: "timestamp" QUERY PLAN= -> Bitmap Heap Scan on point_history (cost=1847.73..286962.53 rows=28554 width=20) (actual time=140998.758..141221.691 rows=192 loops=1) QUERY PLAN= Recheck Cond: (point_id = 21001) QUERY PLAN= Filter: (("timestamp")::text >= '2007-12-11 23:20:57'::text) QUERY PLAN= -> Bitmap Index Scan on point_history_pkey (cost=0.00..1840.59 rows=85663 width=0) (actual time=122.393..122.393 rows=65262 loops=1) QUERY PLAN= Index Cond: (point_id = 21001) QUERY PLAN=Total runtime: 141222.791 ms Cool, this makes it look like the problem is that the "timestamp" parameter as a string instead of a timestamp. What do you think? Tom
В списке pgsql-jdbc по дате отправления: