mao@eden (Mike Olson) (03/01/90)
cast of characters is... >> Tim Wood > Jon Kreuger >>Moreover, one can change the "ordering" of the BLOBs by changing >>the identifier values, whereas with directly-indexed BLOBs one would need >>to change the type-specific indexing algorithm. This amounts to changing >>part of the datatype (or object type) definition. >Sounds like a bad idea to me. I prefer object ordering to be defined >by the object. E.g. you mind if I change ordering of ints? Say by one >application without other applications' knowledge? yeah, subvertibility of this type is indeed a problem, but it arises because ADTs *must* provide some ordering operation if they're to be indexable at all. we are wrestling here with the problem; how much work is done in user space, and how much in "system" space? in the case of BLOB indices, there are pretty important performance considerations, as well. if you need to ship a 20Mbyte bitmap over some IPC channel, you need to redesign. as dr. stonebraker puts it: "wait a minute, let me turn on this fire hose..." note also that there's no reason an application can't provide an *alternative* ordering for an ADT. for bitmaps, for example, you can order by "darkness" or by "size". that makes alternative orderings possible. "changing" an extant ordering proc is probably a bad idea. if i have a bunch of indices that use the less-than operator for integers, and then you change less-than, you haven't just done something confusing, you've made my indices behave incorrectly. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu