Re: [QUESTIONS] Attn PG gurus / coders : New approach for ORDER BY ? (was: Re: Show stopper ?)

From: Jan Vicherek <honza(at)ied(dot)com>
To: "Ron O'Hara" <rono(at)pen(dot)sentuny(dot)com(dot)au>
Cc: pgsql-questions(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [QUESTIONS] Attn PG gurus / coders : New approach for ORDER BY ? (was: Re: Show stopper ?)
Date: 1998-01-24 04:24:00
Message-ID: Pine.LNX.3.96.980123232058.497M-100000@ann.ied.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)ied(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Vicherek 1998-01-24 04:26:31 Re: Attn PG gurus / coders : New approach for ORDER BY ?
Previous Message Jan Vicherek 1998-01-24 04:20:09 Re: [HACKERS] Show stopper ? (was: Re: "cruising" or "browsing" through tables using an index / ordering)