Re: Can this query go faster???

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Joost Kraaijeveld" <J(dot)Kraaijeveld(at)Askesis(dot)nl>
Cc: "Pgsql-Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Can this query go faster???
Date: 2005-12-06 13:58:31
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3417DDA50@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> On Tue, 2005-12-06 at 11:32 +0100, Tino Wildenhain wrote:
> > You can have a row number in postgres easily too. For example if you
> > just include a serial for the row number.
> Not if the order of things is determined runtime and not at insert
time...
>
> > Cursor would work too but you would need to have a persistent
> connection.
> 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)
>
> I guess there is no solution.
>

sure there is. This begs the question: 'why do you want to read exactly
283745 rows ahead of row 'x'?) :)

If you are scrolling forwards in a set, just pull in, say, 100-1000 rows
at a time, ordered, and grab the next 1000 based on the highest value
read previously.

You can do this on server side (cursor) or client side (parameterized
query). There are advantages and disadvantages to each. If you are
looping over this set and doing processing, a cursor would be ideal (try
out pl/pgsql).

Welcome to PostgreSQL! :)

Merlin

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-12-06 14:45:59 Re: Memory Leakage Problem
Previous Message Ron 2005-12-06 13:41:11 Re: Can this query go faster???