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 по дате отправления:

Предыдущее
От: Chris Bitmead
Дата:
Сообщение: Re: [HACKERS] Solution for LIMIT cost estimation
Следующее
От: Don Baccus
Дата:
Сообщение: Re: [HACKERS] Solution for LIMIT cost estimation