|
|
 | | From: | Merlin Moncure | | Subject: | Re: [SQL] OFFSET impact on Performance??? | | Date: | Thu, 20 Jan 2005 12:00:06 -0500 |
|
|
 | > 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
|
|
| | From: | Alex Turner | | Subject: | Re: [SQL] OFFSET impact on Performance??? | | Date: | Thu, 20 Jan 2005 16:35:12 -0500 |
|
|
| 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
NetEconomist
On Thu, 20 Jan 2005 12:00:06 -0500, Merlin Moncure
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
>
>
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
|
|
|
