--On 3. Oktober 2008 19:30:24 +0200 Roché Compaan <[EMAIL PROTECTED]> 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
pgp7VUL5azsqb.pgp
Description: PGP signature
_______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
