Re: Slow query after upgrades

From: Tom Duffey <tduffey(at)techbydesign(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Slow query after upgrades
Date: 2007-12-13 23:27:06
Message-ID: 62EFD840-6C75-4220-9CC3-77D35C76403F@techbydesign.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Tom Lane 2007-12-13 23:31:05 Re: Slow query after upgrades
Previous Message Oliver Jowett 2007-12-13 23:05:46 Re: Slow query after upgrades