AW: LIMIT in DECLARE CURSOR: request for comments

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: AW: LIMIT in DECLARE CURSOR: request for comments
Date: 2000-11-03 08:44:27
Message-ID: 11C1E6749A55D411A9670001FA6879633680E0@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > 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.

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.
It is the correct assumption if the application needs a lot of time
to process each row. If the application processing for each row is fast,
we will still want least total cost.

There is no way for the backend to know this, thus imho the app needs
to give a hint.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message igor 2000-11-03 08:50:36 DateTime functions
Previous Message Karel Zak 2000-11-03 08:05:30 Re: Re: [GENERAL] Query caching