AW: AW: [HACKERS] Another nasty cache problem

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: AW: [HACKERS] Another nasty cache problem
Дата
Msg-id 219F68D65015D011A8E000006F8590C603FDC243@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Список pgsql-hackers
> Zeugswetter Andreas SB wrote:
> > 
> > > Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> > > > What about portals? Doesn't psql use portals?
> > >
> > > No ... portals are a backend concept ...
> > >
> > 
> > I think the previous frontend "monitor" did use a portal for the
> > selects. The so called "blank portal".
> > 
> > I don't really see any advantage, that psql does not do a fetch loop
> > with a portal.
> > Is it possible in psql do do any "fetch" stuff, after doing a
> > select * from table ?
> 
> Yes it is if you set up a cursor. 

My question implied, that a cursor was not set up. That is
type: select * from tab; in psql.

> I think Tom was right that psql
> shouldn't use a portal just as a matter of course, because things
> work differently in that case (locks?).

There is no difference in locking behavior.
So the question remains, why don't we always use a cursor in psql.
It seems the current behavior wastes resources without an obvious
advantage.

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Horák Daniel
Дата:
Сообщение: Small update for WinNT port
Следующее
От: Vince Daniels
Дата:
Сообщение: Re: Postgresql Perl Problem