Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> 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?
> Since we don't have other hints that are embedded directly into the SQL
> that sounds perfect.
> Th
> > 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?
Since we don't have other hints that are embedded directl
Zeugswetter Andreas SB <[EMAIL PROTECTED]> 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 hi
> > 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 d
At 14:14 31/10/00 +0100, Zeugswetter Andreas SB wrote:
>>
>> Which is why I like the client being able to ask the
>> optimizer for certain kinds of solutions *explicitly*.
>
>Yes, something like:
> set optimization to [first_rows|all_rows]
>
That's one way that is usefull for affecting al
> >So I think if you want to make optimization decisions based on cursors
> >being used versus a "normal" select, then the only thing you can safely
> >take into account is the network roundtrip and client processing per
> >fetch, but that might be as random as anything.
>
> Which is why I like
On Mon, 30 Oct 2000, Zeugswetter Andreas SB wrote:
>
> > After thinking some more about yesterday's discussions, I propose that
> > we adopt the following planning behavior for cursors:
> >
> > 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
> > basis of 10%-or-so fetch
> After thinking some more about yesterday's discussions, I propose that
> we adopt the following planning behavior for cursors:
>
> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
> basis of 10%-or-so fetch (I'd consider anywhere from 5% to 25% to be
> just as reasonable,
