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 по дате отправления:

Предыдущее
От: Jan Vicherek
Дата:
Сообщение: Re: [HACKERS] Show stopper ? (was: Re: "cruising" or "browsing" through tables using an index / ordering)
Следующее
От: Jan Vicherek
Дата:
Сообщение: Re: Attn PG gurus / coders : New approach for ORDER BY ?