Re: AW: AW: [HACKERS] Another nasty cache problem
От | Chris Bitmead |
---|---|
Тема | Re: AW: AW: [HACKERS] Another nasty cache problem |
Дата | |
Msg-id | 38A34690.27BCA255@nimrod.itg.telecom.com.au обсуждение исходный текст |
Ответ на | AW: AW: [HACKERS] Another nasty cache problem (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
Zeugswetter Andreas SB wrote: > > > Is'nt the "blank portal" the name of the cursor you get when you just > > do a select without creating a cursor ? > > Yes, is that still so ? > > > > > > I don't really see any advantage, that psql does not do a fetch loop > > > with a portal. > > > > It only increases traffic, as explicit fetch commands need to be sent > > to backend. If one does not declare a cursor, an implicit > > fetch all from > > blank is performed. > > I don't really see how a fetch every x rows (e.g.1000) would add significant > overhead. > The first fetch could still be done implicit, it would only fetch 1000 > instead of fetch all. > Thus there would only be overhead for large result sets, where the > wasted memory is of real concern. Apart from anything else, it would make psql inconvenient for debugging the regular, non-cursor mechanism if psql went off and always used a cursor regardless. And since we know that cursors are not the best way to fix this problem in psql (streaming is the answer), then it doesn't seem a good plan.
В списке pgsql-hackers по дате отправления: