Re: query hangs

Any more idea, please.
Is table partition a good solution for query optimization?

On Fri, Jun 11, 2010 at 11:09 AM, Amit Khandekar <
amit(dot)khandekar(at)enterprisedb(dot)com> wrote:

>
>
> On 10 June 2010 18:47, AI Rumman <rummandba(at)gmail(dot)com> wrote:
>
>> I am using Postgresql 8.1 and did not find FETCH_COUNT
>>
>>
> Oh ok. Looks like FETCH_COUNT was introduced in 8.2
>
>
>> On Thu, Jun 10, 2010 at 6:55 PM, Amit Khandekar <
>> amit(dot)khandekar(at)enterprisedb(dot)com> wrote:
>>
>>>
>>>
>>> On 10 June 2010 18:05, AI Rumman <rummandba(at)gmail(dot)com> wrote:
>>>
>>>> Could you please give me the link for cursor- How to use it?
>>>>
>>>>
>>>> On Thu, Jun 10, 2010 at 6:28 PM, Kevin Grittner <
>>>> Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>>>
>>>>> AI Rumman wrote:
>>>>>
>>>>> >> Merge Left Join (cost=9500.30..101672.51 rows=2629549 width=506)
>>>>>
>>>>> > And the query does not return data though I have been waiting for
>>>>> > 10 mins.
>>>>> >
>>>>> > Do you have any idea ?
>>>>>
>>>>> Unless you use a cursor, PostgreSQL interfaces typically don't show
>>>>> any response on the client side until all rows have been received and
>>>>> cached on the client side. That's estimated to be over 2.6 million
>>>>> rows in this case. That can take a while.
>>>>>
>>>>> You might want to use a cursor....
>>>>>
>>>>>
>>>
>>> If you are using psql client, using FETCH_COUNT to a small value will
>>> allow you to achieve cursor behaviour. psql starts returning batches of
>>> FETCH_COUNT number of rows .
>>>
>>> E.g. \set FETCH_COUNT 1
>>> will start fetching and displaying each row one by one.
>>>
>>>
>>>
>>>
>>> -Kevin
>>>>>
>>>>
>>>>
>>>
>>
>