Re: [QUESTIONS] Attn PG gurus / coders : New approach for ORDER BY ? (was: Re: Show stopper ?)
От | Jan Vicherek |
---|---|
Тема | Re: [QUESTIONS] Attn PG gurus / coders : New approach for ORDER BY ? (was: Re: Show stopper ?) |
Дата | |
Msg-id | Pine.LNX.3.96.980123232058.497M-100000@ann.ied.com обсуждение исходный текст |
Ответ на | Re: [QUESTIONS] Attn PG gurus / coders : New approach for ORDER BY ? (was: Re: Show stopper ?) ("Ron O'Hara" <rono@pen.sentuny.com.au>) |
Список | pgsql-hackers |
Here is another exact perfect descrtiption of what I mean : (you don't have to read it again, it's only repost) Jan On Sat, 24 Jan 1998, Ron O'Hara wrote: > On Fri, 23 Jan 1998, Jan Vicherek wrote: > [big chop] > > > This looks like a sad suggestion to me. I'll kick and scream just that > > I wouldn't have to go with Velocis RAIMA's lower-level C interface. (I'm > > just staring into its manual to figure out the sequence of C calls I would > > have to make to accomplish this.) > > If it is still the same as when it was called DBVista... then > > d_keyfind(xx,x,x) > while(db_status == S_OK) > { > d_recread(x,x,x,x); > d_keynext(ssss); > } > (No error checking in that code...<g>) > > ------------ end Raima note ------------------------------------ Yea, it seems like that would be still the same ... thanx for saving me the time ! :) v--- Yes, yes yes, this is exactly what I'm trying to accompliesh ---v > BUT - the functionality you want could be a special case of the Postgres > backend and would benefit a very important real world scenario > (scrolling inquiries) > > IF - declare cursor > and select 'whole table' > and 'order by a field which is a key' > > Treat as special - dont handle ANY data until the FETCH statement. > IE. Defer the IO until the fetch happens - then access the row(s) > via the index > > This would give an enormous boost in effective performance with the common > application task of a scrolling inquiry against a large table. > Implementing it would be transparent to current application code and would > offer a competitive edge over other products without it. yes yes yes > Normally I'm not one to support 'special case' coding tricks, but the > public impact on visible performance probably justifies looking into this > a bit further. > I suspect the query processor can identify the situation. It would need to > remember that it was special and leave enough control info to allow the > 'fetch' processing to respond to that special case. > > Comments from the guru's who are up to their necks in the code ? ( I am eager ;-) Jan -- Gospel of Jesus is the saving power of God for all who believe -- Jan Vicherek ## To some, nothing is impossible. ## www.ied.com/~honza >>> Free Software Union President ... www.fslu.org <<< Interactive Electronic Design Inc. -#- PGP: finger honza@ied.com
В списке pgsql-hackers по дате отправления: