Re: Large selects handled inefficiently?
От | Jules Bean |
---|---|
Тема | Re: Large selects handled inefficiently? |
Дата | |
Msg-id | 20000830143251.D15150@grommit.office.vi.net обсуждение исходный текст |
Ответ на | RE: Large selects handled inefficiently? ("Andrew Snow" <als@fl.net.au>) |
Ответы |
RE: Large selects handled inefficiently?
|
Список | pgsql-general |
On Thu, Aug 31, 2000 at 12:22:36AM +1000, Andrew Snow wrote: > > > I believe I can work around this problem using cursors (although I > > don't know how well DBD::Pg copes with cursors). However, that > > doesn't seem right -- cursors should be needed to fetch a large query > > without having it all in memory at once... > > Actually, I think thats why cursors were invented in the first place ;-) A > cursor is what you are using if you're not fetching all the results of a > query. I really can't agree with you there. A cursor is another slightly foolish SQL hack. A query language specifies the syntax of queries ('SELECT ...'). It doesn't specify the manner in which these are actually returned. It seems totally within the bounds of the remit of a decent client-side library (and a decent back-end) to realise that in practice a client will want some control over the speed with which rows are returned. Whilst explicit cursors are needed for some (IMO ugly) procedural SQL code, explicit cursors should not be necessary for the simple (and common) task of carrying out a SELECT which takes up more memory than you wish to have available at any single time. Jules
В списке pgsql-general по дате отправления: