
[To hackers this time]

At 20:59 26/10/00 -0400, Tom Lane wrote:
>Hiroshi Inoue <Inoue@tpf.co.jp> 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.



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Fri, 27 Oct 2000 21:21:23 +1000
Philip Warner <pjw@rhyme.com.au>
Re: [COMMITTERS] pgsql/src/backend/nodes (copyfuncs.c
	outfuncs.c print.c)
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 <Inoue@tpf.co.jp> 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.

Fri, 27 Oct 2000 12:41:50 -0500
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Re: [COMMITTERS] pgsql/src/backend/nodes (copyfuncs.c outfuncs.c
	print.c)