AW: AW: [HACKERS] Another nasty cache problem

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'chris(at)bitmead(dot)com'" <chris(at)bitmead(dot)com>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: AW: AW: [HACKERS] Another nasty cache problem
Date: 2000-02-09 13:33:52
Message-ID: 219F68D65015D011A8E000006F8590C603FDC243@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> Zeugswetter Andreas SB wrote:
> >
> > > Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message FixerRM 2000-02-09 14:10:21 jdbc and sequences --RM
Previous Message Horák Daniel 2000-02-09 10:30:33 Small update for WinNT port