Forum OpenACS Development: Response to New implementation of tree_sortkey

Collapse
Posted by Don Baccus on
I don't think wider keys significantly slow down queries - indexing's the big deal here.  Once they're used, queries run fast.

But reducing the space overhead seems important to me if we can do so without penalizing ourselves in some other significant way.  There are all sorts of reasons for this.  A simple one - in PG, when you join tables you drag rows around, so the longer rows are the more time is spent in byte-shuffling.  I mentioned the impact on indexes somewhere above in a previous post, I think.

I think the 7-bit/31-bit split is a reasonable compromise.  While the text approach implemented unlimited keys (I think I confused your implementation with Philip's old 2-char-per-level implementation for bboard), 2^31 (2 billion plus) direct ancestors per node should be sufficient.

There's no way to use a delimiter ala the text approach unless we go to unary rather than binary keys! :)  Getting rid of the collation dependency (LANG=C) was the only reason I switched representations...