Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>> basis of 10%-or-so fetch
> 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.
It remains to argue about what the relative weighting ought to be
... which might be best answered by making it user-settable.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Jade Rubick||Date: 2000-11-02 17:26:50|
|Subject: Another remove request|
|Previous:||From: Tom Lane||Date: 2000-11-02 17:20:39|
|Subject: Re: relation ### modified while in use |