From: | Thomas Vatter <thomas(dot)vatter(at)network-inventory(dot)de> |
---|---|
To: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
Cc: | Tino Wildenhain <tino(at)wildenhain(dot)de>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: in memory views |
Date: | 2006-05-10 20:54:00 |
Message-ID: | 446252E8.8000304@network-inventory.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Scott Marlowe wrote:
>On Wed, 2006-05-10 at 10:41, Thomas Vatter wrote:
>
>
>>Scott Marlowe wrote:
>>
>>
>
>
>
>>>What happens if you do this by declaring it as a cursor and then
>>>fetching the first row?
>>>
>>>
>
>
>
>>>
>>>
>>>
>>I do executeQuery(), for the resultSet I do next() and return one row,
>>but wait, I have to review the logic in this area, I can tell you
>>tomorrow
>>
>>
>
>
>A good short test is to run explain analyze on the query from the psql
>command line. If it shows an execution time of significantly less than
>what you get from you application, then it is likely that the real
>problem is that your application is receiving the whole result set via
>libpq and waiting for that. A cursor will solve that problem.
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
>
>
Yes, the difference between psql command line and application is 6
seconds to 40 seconds. It is
exactly the step resultSet = excecuteQuery() that needs 40 seconds. I
use next() as a cursor
through the resultSet, but I fear this is not enough, do I have to use
createStatement(resultSetType,
resultSetConcurrency) respectively prepareStatement (resultSetType,
resultSetConcurrency) to
achieve the cursor behaviour?
regards
tom
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-05-10 21:01:22 | Re: in memory views |
Previous Message | PFC | 2006-05-10 19:35:39 | Re: [HACKERS] Big IN() clauses etc : feature proposal |