From: Tino Wildenhain <tino@wildenhain.de>
To: Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>
Cc: Csaba Nagy <nagy@ecircle-ag.com>
Cc: Pgsql-Performance <pgsql-performance@postgresql.org>
Subject: Re: Can this query go faster???
Date: Tue, 06 Dec 2005 13:30:25 +0100
Message-ID: <43958461.2060106@wildenhain.de> (raw)
In-Reply-To: <1133871645.8837.78.camel@Panoramix>
References: <1133862229.8837.61.camel@Panoramix>
<1133862777.4779.185.camel@coppola.muc.ecircle.de>
<1133864460.8837.69.camel@Panoramix>
<439568C4.8050601@wildenhain.de>
<1133868084.8837.73.camel@Panoramix>
<439577D2.9090208@wildenhain.de>
<1133871645.8837.78.camel@Panoramix>
Joost Kraaijeveld schrieb:
> On Tue, 2005-12-06 at 12:36 +0100, Tino Wildenhain wrote:
>
>>>I just tried it: a cursor is not faster (what does not surprise me at
>>>all, as the amount of work looks the same to me)
>>
>>Actually no, if you scroll forward, you just ask the database for the
>>next rows to materialize. So if you are ahead in your database and
>>ask for next rows, it should be faster then working w/ an offset
>>from start each time.
>
> Ah, a misunderstanding: I only need to calculate an index if the user
> wants a record that is not in or adjacent to the cache (in which case I
> can do a "select values > last value in the cache". So I must always
> materialize all rows below the wanted index.
>
Yes, but still advancing a few blocks from where the cursor is
should be faster then re-issuing the query and scroll thru
the whole resultset to where you want to go.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tino@wildenhain.de, J.Kraaijeveld@Askesis.nl, nagy@ecircle-ag.com
Subject: Re: Can this query go faster???
In-Reply-To: <43958461.2060106@wildenhain.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox