X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (mx2.hub.org [200.46.204.254])
	by postgresql.org (Postfix) with ESMTP id D4DCD11F60B0
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 21 Apr 2006 01:42:30 -0300 (ADT)
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 required=5 tests=[BAYES_00=-2.599,
	HTML_MESSAGE=0.001, SPF_PASS=-0.001]
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx2.hub.org [200.46.204.254]) (amavisd-new, port 10024)
	with ESMTP id BH3dmPlFi3Wc
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 21 Apr 2006 01:42:25 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-
Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.181])
	by postgresql.org (Postfix) with ESMTP id D924311F6077
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Apr 2006 01:42:24 -0300 (ADT)
Received: by pproxy.gmail.com with SMTP id x66so381661pye
	for <pgsql-performance@postgresql.org>;
	Thu, 20 Apr 2006 21:42:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=o2KCLEQMJA+xUO+JEueetCdtymOTK6F5iw6yUlrG2i5Pv+vLNgwfmuiXQj79qWBlaxJ6+zzBf1JUPyaNUe+0DzZ1jyQtD3GbUWiv5KQWUFcsA8A9l8JGeaJEWiojbHXtjvOI/UNtjY10uKjSqI3mpLCOHjHM83EKxqQrR1r4gQw=
Received: by 10.35.97.17 with SMTP id z17mr1998052pyl;
	Thu, 20 Apr 2006 21:42:24 -0700 (PDT)
Received: by 10.35.31.15 with HTTP; Thu, 20 Apr 2006 21:42:24 -0700 (PDT)
Message-ID: <9f2e40a90604202142x5adbe6f0r7a993f8319619cc7@mail.gmail.com>
Date: Fri, 21 Apr 2006 10:12:24 +0530
From: "soni de" <soni.de@gmail.com>
To: "Merlin Moncure" <mmoncure@gmail.com>
Subject: Re: Takes too long to fetch the data from database
Cc: pgsql-performance@postgresql.org
In-Reply-To: <b42b73150604200905h56a0d387xec8c80b4c8d3e901@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_13063_2413221.1145594544005"
References: <9f2e40a90604100021n1cb694d0lb95f318f800f33ee@mail.gmail.com>
	<b42b73150604100845w553dcee6kde20e4b82770aab0@mail.gmail.com>
	<9f2e40a90604110004u787716c2s22bdf53fe349326@mail.gmail.com>
	<b42b73150604110613h2c63ea61oec8035c8e2f4ed98@mail.gmail.com>
	<9f2e40a90604192237i5d3e8f0dl1c8b19887bc34e22@mail.gmail.com>
	<b42b73150604200905h56a0d387xec8c80b4c8d3e901@mail.gmail.com>
X-Archive-Number: 200604/490
X-Sequence-Number: 18574

------=_Part_13063_2413221.1145594544005
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I don't want to query exactly 81900 rows into set. I just want to fetch 50
or 100 rows at a time in a decreasing order of stime.(i.e 50 or 100 rows
starting from last to end).

if we fetched sequentially, there is also problem in fetching all the
records (select * from wan where kname=3D'pluto' order by stime) it is taki=
ng
more than 4~5 minutes. tried it on same table having more than 326054
records.


On 4/20/06, Merlin Moncure <mmoncure@gmail.com> wrote:
>
> > SELECT * FROM wan ORDER BY stime LIMIT 50 OFFSET 81900;
>
> you need to try and solve the problem without using 'offset'.  you could
> do:
> BEGIN;
> DECLARE crs cursor FOR SELECT * FROM wan ORDER BY stime;
> FETCH ABSOLUTE 81900 in crs;
> FETCH 49 in crs;
> CLOSE crs;
> COMMIT;
>
> this may be a bit faster but will not solve the fundamental problem.
>
> the more interesting question is why you want to query exactly 81900
> rows into a set.  This type of thinking will always get you into
> trouble, absolute positioning will not really work in a true sql
> sense.  if you are browsing a table sequentially, there are much
> better methods.
>
> merlin
>

------=_Part_13063_2413221.1145594544005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>I don't want to query exactly 81900 rows into set. I just want to fetc=
h 50 or 100 rows at a time in a decreasing order of stime.(i.e 50 or 100 ro=
ws starting from last to end).</div>
<div>&nbsp;</div>
<div>if we fetched sequentially, there is also problem in fetching all the =
records (select * from wan&nbsp;where kname=3D'pluto' order by stime) it is=
 taking more than 4~5 minutes. tried it on same table having more than 3260=
54 records.
</div>
<div><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 4/20/06, <b class=3D"gmail_sendername">=
Merlin Moncure</b> &lt;<a href=3D"mailto:mmoncure@gmail.com">mmoncure@gmail=
.com</a>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">&gt; SELECT * FROM wan ORDER BY =
stime LIMIT 50 OFFSET 81900;<br><br>you need to try and solve the problem w=
ithout using 'offset'.&nbsp;&nbsp;you could do:
<br>BEGIN;<br>DECLARE crs cursor FOR SELECT * FROM wan ORDER BY stime;<br>F=
ETCH ABSOLUTE 81900 in crs;<br>FETCH 49 in crs;<br>CLOSE crs;<br>COMMIT;<br=
><br>this may be a bit faster but will not solve the fundamental problem.
<br><br>the more interesting question is why you want to query exactly 8190=
0<br>rows into a set.&nbsp;&nbsp;This type of thinking will always get you =
into<br>trouble, absolute positioning will not really work in a true sql<br=
>sense.&nbsp;&nbsp;if you are browsing a table sequentially, there are much
<br>better methods.<br><br>merlin<br></blockquote></div><br>

------=_Part_13063_2413221.1145594544005--