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

From Hannu Krosing
Subject Re: AW: AW: [HACKERS] Another nasty cache problem
Date
Msg-id 38A484C1.7EE47CDD@tm.ee
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 ?

>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


pgsql-hackers by date:

Previous
From: Patrick Welche
Date:
Subject: Re: [HACKERS] Another nasty cache problem
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Another nasty cache problem