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