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.
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 |