On Fri, Oct 27, 2000 at 09:21:23PM +1000, Philip Warner wrote:
[To hackers this time]
At 20:59 26/10/00 -0400, Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Yes I want to give optimizer a hint "return first rows fast".
When Jan implemented LIMIT first,there was an option
"LIMIT ALL" and it was exactly designed for the purpose.
Well, we could make that work that way again, I think.
I think that would be a *bad* idea. ISTM that the syntax is obtuse for the
meaning it is being given. The (mild) confusion in this thread is evidence
of that, at least.
Syncronicity, man. I didn't see the beginning of this thread (not on
COMMITERS) so I may be repeating things from there.
I was recently cleaning out a stack of old trade-rags lying around, and
snipped an article out of a DB2 mag I've been getting. Very technical,
and discusses the uses (and abuses) of OPTIMIZE FOR N ROWS, where N is
an actual number. Discusses how the DB2 optimizer will use this hint to
decide if it should use an index to get the right order, even if it's a
full scan, and the total cost might be higher. I'll see if I can find it
online, if anyones interested.
The original article is all in the context of cursors (and multi-gig
tables), but I think LIMIT brings in many of the same optimization
considerations.
ISTM that the most common use of LIMIT right now is to simulate a cursor
to provide some state over the stateless HTTP protocol, no? So the LIMIT
is not 'fast start' vs 'total cost': the webpage often allows the enduser
to select the batchsize. At some batchsize, 'total cost' wins over a
simplistic 'fast start' approach. And only the optimizer has any hope of
figuring out where that might be, as it will change with the exact query
structure.
Ross
--
Open source code is like a natural resource, it's the result of providing
food and sunshine to programmers, and then staying out of their way.
[...] [It] is not going away because it has utility for both the developers
and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
