Re: AW: AW: [HACKERS] Another nasty cache problem

From: Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'Hannu Krosing'" <hannu(at)tm(dot)ee>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'chris(at)bitmead(dot)com'" <chris(at)bitmead(dot)com>, "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: AW: AW: [HACKERS] Another nasty cache problem
Date: 2000-02-10 23:15:28
Message-ID: 38A34690.27BCA255@nimrod.itg.telecom.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Don Baccus 2000-02-10 23:23:48 Re: [HACKERS] Solution for LIMIT cost estimation
Previous Message Chris Bitmead 2000-02-10 23:01:46 Re: [HACKERS] Solution for LIMIT cost estimation