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
Peter Eisentraut <[EMAIL PROTECTED]> 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'r
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
At 10:51 31/10/00 +0100, Peter Eisentraut wrote:
>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 y
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 programmi
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,
At 12:18 PM 10/27/00 -0400, Tom Lane wrote:
>Hiroshi was a little concerned about this change in behavior, and
>so the first order of business is whether anyone wants to defend the
>old way? IMHO it was incontrovertibly a bug, but ...
Sure feels like a bug to me. Having it ignored isn't what I
At 12:18 27/10/00 -0400, Tom Lane wrote:
>
>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, if people want to argue about the exact number;
>perhaps a SET variable is in order?). 10%
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:18 27/10/00 -0400, Tom Lane wrote:
>> 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, if people want to argue about the exact numb
Hiroshi and I had a discussion last night that needs to reach a wider
audience than just the bystanders on pgsql-committers. Let me see if
I can reconstruct the main points.
In 7.0, a LIMIT clause can appear in a DECLARE CURSOR, but it's ignored:
play=> select * from vv1;
f1
-
15 matches
Mail list logo
