Re: AW: AW: [HACKERS] Another nasty cache problem - Mailing list pgsql-hackers

From Chris Bitmead
Subject Re: AW: AW: [HACKERS] Another nasty cache problem
Date
Msg-id 38A34690.27BCA255@nimrod.itg.telecom.com.au
Whole thread Raw
In response to AW: AW: [HACKERS] Another nasty cache problem  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List 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 by date:

Previous
From: Chris Bitmead
Date:
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Next
From: Don Baccus
Date:
Subject: Re: [HACKERS] Solution for LIMIT cost estimation