>
> I completely agree that we need to break the documents up more and I
> also agree with your reasons for needing to do so, however I'm very
> hesitant to go all the way to individual nodes. The are several reasons
> for this. One is that the current BTree is really slow, in fact it's
> faster to
Kimbro Staken wrote:
[...]
I completely agree that we need to break the documents up more and I
also agree with your reasons for needing to do so, however I'm very
hesitant to go all the way to individual nodes. The are several reasons
for this. One is that the current BTree is really slow, in f
Kimbro Staken wrote:
The second thing I'm exploring in this area, is a different way to
partition an XML document into pieces. I've been exploring horizontal
partitioning where all sibling nodes would be stored together in a
single record. In a lot of ways this is pretty similar to how relationa
On Monday, December 23, 2002, at 04:44 PM, James Bates wrote:
Here's the stuff I think we could get started with in the core
development
field:
1) storage:
===
Currently XML is stored by "compressing it", which in fact involves
flattening the tree into a byte-array, and replacing
all element
o: <[EMAIL PROTECTED]>
Sent: Tuesday, December 24, 2002 1:34 AM
Subject: RE: core development
> If you store every node as its own record then you will have spatial
> issues reconstructing documents as there is no guarantee that all the
> nodes for any particular document will be loc
If you store every node as its own record then you will have spatial
issues reconstructing documents as there is no guarantee that all the
nodes for any particular document will be located in the same area of a
disk.
If you do in fact want to store each node separately, you will need to
create som
