From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: LIMIT in DECLARE CURSOR: request for comments |
Date: | 2000-11-02 17:24:52 |
Message-ID: | 25839.973185892@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jade Rubick | 2000-11-02 17:26:50 | Another remove request |
Previous Message | Tom Lane | 2000-11-02 17:20:39 | Re: relation ### modified while in use |