Re: query hangs - Mailing list pgsql-performance

From Amit Khandekar
Subject Re: query hangs
Date
Msg-id AANLkTimOFrRQ46vduEEJfWtJ029j191VLuMC_rgTNrYh@mail.gmail.com
Whole thread Raw
In response to Re: query hangs  (AI Rumman <rummandba@gmail.com>)
Responses Re: query hangs
List pgsql-performance


On 10 June 2010 18:47, AI Rumman <rummandba@gmail.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.khandekar@enterprisedb.com> wrote:


On 10 June 2010 18:05, AI Rumman <rummandba@gmail.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.Grittner@wicourts.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




pgsql-performance by date:

Previous
From: David Jarvis
Date:
Subject: Re: Analysis Function
Next
From: Bob Lunney
Date:
Subject: Re: requested shared memory size overflows size_t