Обсуждение: AW: AW: [HACKERS] Another nasty cache problem

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

Andreas

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.

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 ?

>From my toy implementation of fe-be protocol in python for v.6.2 I 
remember it to be, i.e. the cursors name is blank if 
declare cursor ;fetch all ...
is implicit

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

But it would start a transaction and possibly lock the table as well.

> The first fetch could still be done implicit, it would only fetch 1000
> instead of fetch all.

maybe we should add a macro language to psql and thus make it into something 
else, like pgsh ;)

> Thus there would only be overhead for large result sets, where the
> wasted memory is of real concern.

The whole fe-be protocol should be re-thought at some stage (or an additional 
protocol + client libs added) anyway, as current one is quite weak at XOPEN
CLI 
support both ODBC and JDBC drivers are full of hacks to be compatible with 
standard usages. Also performance suffers on inserts adn selects as prepared 
queries can't be currently used from client programs (they can from SPI).



-------------------
Hannu