It'd be useful to know more about your measurement scales. Evgeni remarks that for his applications, units can be
brokendown into simple linear combinations of fundamental units --- but if you're doing something like converting
betweendifferent device-dependent color spaces, I can well believe that that model wouldn't work...
Those ideas about linear combinations are great, but I think too
simplistic for what I have in mind. I'll give it more thought,
though, as I further define the structure of all the interconversions.
> - How much of an overhead is introduced by requiring the backend to > query system tables during tuple
processing? Is this unacceptable > from the outset or is it reasonable to consider this option further?
Assuming that the scale tables are not too large and not frequently changed, the ideal access mechanism seems to be
the"system cache" mechanism (cf src/backend/utils/cache/syscache.c, src/backend/utils/cache/lsyscache.c). The cache
supportallows each backend to keep copies in memory of recently-used rows of a cached table. Updating a cached table
requiresrather expensive cross- backend signaling, but as long as that doesn't happen often compared to accesses, you
win. The only real restriction is that you have to look up cached rows by a unique key that corresponds to an index,
but that seems not to be a problem for your application.
I have in mind cases in which the system tables will almost never be
updated. That is, the table installed initially will serve the vast
majority of purposes, but I'd still like the flexibility of updating
it when needed. Caches may very well be perfectly appropriate, here;
thanks for the pointer.
Adding a new system cache is a tad more invasive than the usual sort of user-defined-type addition, but it's
certainlynot out of the question. Bruce Momjian has done it several times and documented the process, IIRC.
Bruce, is that the case? Do you really have it documented? If so,
where?
Cheers,
Brook