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

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'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-11 21:53:05
Message-ID: 38A484C1.7EE47CDD@tm.ee
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 ?

>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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-02-11 23:18:32 Re: [HACKERS] Another nasty cache problem
Previous Message Patrick Welche 2000-02-11 21:04:42 Re: [HACKERS] Another nasty cache problem