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

Fri, 3 Nov 2000 09:44:27 +0100 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: LIMIT in DECLARE CURSOR: request for comments 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> 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.

Sure ...

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

Right.  So what do you think about a hint that takes the form of a SET
variable for the fetch percentage to assume for a DECLARE CURSOR?

			regards, tom lane

Fri, 03 Nov 2000 11:10:55 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: LIMIT in DECLARE CURSOR: request for comments 