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.khande...@enterprisedb.com> wrote: > > > On 10 June 2010 18:47, AI Rumman <rumman...@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.khande...@enterprisedb.com> wrote: >> >>> >>> >>> On 10 June 2010 18:05, AI Rumman <rumman...@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.gritt...@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 >>>>> >>>> >>>> >>> >> >
