[Product-Developers] Design advise for collective.alchemyindex

[Andreas Jung]

--On 3. Oktober 2008 19:30:24 +0200 Roché Compaan 
<roche at upfrontsystems.co.za> wrote:

> My motivation for doing this is in the first place is because of the
> poor performance and size of indexes in the ZODB. See my post about it
> here:
> http://www.upfrontsystems.co.za/Members/roche/where-im-calling-from/catal
> og-indexes
>
> Conflict errors in the portal catalog gives me another reason to explore
> alternatives.

As mentioned my benchmarks were made at least three years ago.

In index implementation you have have ti manage mappings like

 Int -> [Int1, Int2, ..]

The simplest implementation would use a 1:N relation. 
Indexing/unindexing/reindex operation will result in tons of INSERt/UPDATE 
and DELETE operations. If with RDBMS specific optimizations I could not 
reach a comparable performance.

For a recent project (with similar needs) I represent the list of XXX as 
arrays in Postgres. This results in a reasonable application performance 
but introduces an overhead since you have to store/load the array all 
together.
My current implementation is still based on SA 0.3...possibly SA 0.4/0.5
provides a better PG array support.

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-product-developers/attachments/20081003/7e52cc44/attachment.asc>