Skip site navigation (1) Skip section navigation (2)

AW: LIMIT in DECLARE CURSOR: request for comments

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: AW: LIMIT in DECLARE CURSOR: request for comments
Date: 2000-11-03 08:44:27
Message-ID: 11C1E6749A55D411A9670001FA6879633680E0@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> > I'd say that normally you're not using cursors because you intend to throw
> > away 80% or 90% of the result set, but instead you're using it because
> > it's convenient in your programming environment (e.g., ecpg).  There are
> > other ways of getting only some rows, this is not it.
> 
> I didn't say I was assuming that the user would only fetch 10% of the
> rows.  Since what we're really doing is a linear interpolation between
> startup and total cost, what this is essentially doing is favoring low
> startup cost, but not to the complete exclusion of total cost.
> I think that that describes the behavior we want for a cursor pretty well.

I did understand this, but I still disagree. Whether this is what you want
strongly depends on what the application does with the resulting rows.
It is the correct assumption if the application needs a lot of time 
to process each row. If the application processing for each row is fast,
we will still want least total cost. 

There is no way for the backend to know this, thus imho the app needs
to give a hint. 

Andreas

Responses

pgsql-hackers by date

Next:From: igorDate: 2000-11-03 08:50:36
Subject: DateTime functions
Previous:From: Karel ZakDate: 2000-11-03 08:05:30
Subject: Re: Re: [GENERAL] Query caching

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group