Thread: Re: [COMMITTERS] pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
[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 |/
Re: Re: [COMMITTERS] pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
From
"Ross J. Reedstrom"
Date:
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.