Re: [SQL] OFFSET impact on Performance???
От | Alex Turner |
---|---|
Тема | Re: [SQL] OFFSET impact on Performance??? |
Дата | |
Msg-id | 33c6269f05012013354ebf8bd8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [SQL] OFFSET impact on Performance??? ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
Список | 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 NetEconomist On Thu, 20 Jan 2005 12:00:06 -0500, Merlin Moncure <merlin.moncure@rcsonline.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 > >
В списке pgsql-performance по дате отправления: