Brook Milligan <brook@biology.nmsu.edu> writes:
> Along with each data item, I must keep additional information about
> the scale of measurement. Further, the relevant scales of measurement
> fall into a few major families of related scales, so at least a
> different type will be required for each of these major families.
> Additionally, I wish to be able to convert data measured according to
> one scale into other scales (both within the same family and between
> different families), and these interconversions require relatively
> large sets of parameters.
It'd be useful to know more about your measurement scales. Evgeni
remarks that for his applications, units can be broken down into
simple linear combinations of fundamental units --- but if you're
doing something like converting between different device-dependent
color spaces, I can well believe that that model wouldn't work...
> - 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 support allows each
backend to keep copies in memory of recently-used rows of a cached
table. Updating a cached table requires rather 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.
Adding a new system cache is a tad more invasive than the usual sort of
user-defined-type addition, but it's certainly not out of the question.
Bruce Momjian has done it several times and documented the process,
IIRC.
regards, tom lane
