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.
The not so
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 hint.
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
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're using
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
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 you're
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 all
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, if
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 (I'd
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'd
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
-
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 number;
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%
13 matches
Mail list logo
