
> > 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 directly into the SQL
that sounds perfect. 

The not so offhand question for me is whether to use this percentage for 
non cursor selects also. Imho both should (at least in default) behave the same.

Andreas

Fri, 3 Nov 2000 17:32:21 +0100 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: AW: LIMIT in DECLARE CURSOR: request for comments 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> 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 offhand question for me is whether to use this percentage
> for non cursor selects also. Imho both should (at least in default)
> behave the same.

Not at all, since in a non-cursor select you *must* retrieve all the
data.  I can't see any reason to optimize that on any other basis than
total execution time.

			regards, tom lane

Fri, 03 Nov 2000 11:59:49 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: AW: LIMIT in DECLARE CURSOR: request for comments 