[elephant-devel] Re: Severely poor performance in some obvious cases

[Alex Mizrahi]

 ??>> I'm surprised you are seeing this difference on Postmodern, unless
 ??>> your input name is matching a large number of objects (i.e. s is
 ??>> large).  I had thought that the native PostgreSQL backend,
 ??>> postmodern,
 ??>> fixed the linear cost problem of CL-SQL indices and provides the
 ??>> same
 ??>> O(s) performance that BDB does, but I'm not certain (Henrik?
 ??>> Robert?).  It sounds like you are seeing a high linear cost.

 RLR> Postmodern does exactly the same thing that CL-SQL does in this
 RLR> respect; the code was copied directly from the CL-SQL code.

from original Henrik's announcement:

----
The implementation is actually quite different from
the clsql backend.
...
The db-postmodern cursor is based on a sql cursor. Each btree has its
own database table.
----

 IE> SQL backend cannot support the ordering constraints of an index
 IE> without reading all the objects into memory

and postmodern cannot support them too.
however we do not really need to support ordering to do by-value queries.
as for by-range queries, they should work in db-postmodern when keys are 
strings-only or integers-only, which is probably most useful case. we are 
going to improve it to support NILs among values.

by the way, "ugly fix" Henrik mentions in original post is blocking range 
queries. for now we cannot even do even by-value queries because of "special 
way" map-index works, so "ugly fix" is needed.

but we are going to provide optimized specialization for doing by-value 
queries, and fix stuff so by-range queries will work at least in some 
limited way.

also in process of improving cursor implementation we are going to provide 
optional "compatible" mode that will allow degrading to CLSQL backend style 
(fetch everything and sort on Lisp side), so people who want to do funky 
range queries will be able to do so, but they will loose ability to work 
with arbitrarily large tables.

it might be possible to implement lisp-compare in postgres somehow, but IMHO 
it doesn't worth effort to do so -- range queries make sense when you know 
type of data.