On Tue, 29 Mar 2005 12:27:51 +0900, Jamey Cribbs <jcribbs / twmi.rr.com> wrote:
> Bill Guindon wrote:
> 
> >Out of curiosity, can you 'declare' sorts to be ascending by using a '+'?
> >
> >Can this:
> >  result_set = plane_tbl.select(:name, :country, :speed).sort(:country, -:speed)
> >
> >Be written like this?:
> >  result_set = plane_tbl.select(:name, :country,
> >:speed).sort(+:country, -:speed)
> >
> Currently, no.  The default is ascending.  However, if there is a need
> to explicitly specify ascending, I could add it.

No "need", just like to explicitly declare things when I can.  I seek
symmetry :)
 
> >Also out of curiosity, have you thought about adding indexing?  Could
> >just use a different file extension, and rebuild them while 'packing'.
> >
> >
> I've thought about it, but that's about it.  :-)
> If we are talking about adding it for speed purposes, right now,
> KirbyBase is reasonably fast.  While coding this new version, I did a
> very rough benchmark on a 80,000 record table.  The query did a select
> on a date range and returned 23,000 records.  I coded the query in both
> KirbyBase and SQLite and was mildly surprised to see KirbyBase finish
> about 2 seconds faster than SQLite.  Granted, this test was EXTREMELY
> un-scientific and I am not trying to say in any way that I think
> KirbyBase can match SQLite's performance.  I just wanted to point out
> that, for small databases, KirbyBase feels pretty responsive, so I am
> not sure if there is a need right now to increase the complexity of
> KirbyBase by adding indexing solely for speed.

Nice results, even if it strays a bit, still sounds good.
 
> If there would be other good reasons for adding indexing, I'm all ears. :-)

To combine search with sorts?  If I can index on date descending, name
ascending, speed descending, etc.  Seems the index would be faster
than doing the sorts.  Could be wrong tho'.

-- 
Bill Guindon (aka aGorilla)