Skip site navigation (1) Skip section navigation (2)

Re: [SQL] OFFSET impact on Performance???

From: Alex Turner <armtuk(at)gmail(dot)com>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org,Richard Huxton <dev(at)archonet(dot)com>
Subject: Re: [SQL] OFFSET impact on Performance???
Date: 2005-01-20 21:35:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
How do you create a temporary view that has only a small subset of the
data from the DB init?  (Links to docs are fine - I can read ;).  My
query isn't all that complex, and my number of records might be from
10 to 2k depending on how I implement it.

Alex Turner

On Thu, 20 Jan 2005 12:00:06 -0500, Merlin Moncure
<merlin(dot)moncure(at)rcsonline(dot)com> wrote:
> > I am also very interesting in this very question.. Is there any way to
> > declare a persistant cursor that remains open between pg sessions?
> > This would be better than a temp table because you would not have to
> > do the initial select and insert into a fresh table and incur those IO
> > costs, which are often very heavy, and the reason why one would want
> > to use a cursor.
> Yes, it's called a 'view' :-)
> Everything you can do with cursors you can do with a view, including
> selecting records in blocks in a reasonably efficient way.  As long as
> your # records fetched is not real small (> 10) and your query is not
> super complex, you can slide your view just like a cursor with zero real
> impact on performance.
> If the query in question does not scale in time complexity with the
> amount of data returned (there is a fix processing step which can't be
> avoided), then it's materialized view time, such that they can be done
> in PostgreSQL.
> Now, cursors can be passed around in pl/pgsql functions which makes them
> very useful in that context.  However, for normal data processing via
> queries, they have some limitations that makes them hard to use in a
> general sense.
> Merlin

In response to

pgsql-performance by date

Next:From: Russell SmithDate: 2005-01-20 21:38:19
Subject: Re: index scan of whole table, can't see why
Previous:From: Mark KirkwoodDate: 2005-01-20 21:05:47
Subject: Re: PostgreSQL clustering VS MySQL clustering

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group