Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.postgresql > #370

"Priming" a base type's internal cache

Show all headers | View raw

Hi,

I have a custom base type that relies heavily on caching
for many of the functions derived from those values.  I'm
looking for suggestions as to how to "prime" the cache of
those function values.

E.g., imagine the type was used to define a "circle" as a center
and a radius.  Then these functions might be things like area(),
circumference(), etc. -- except those are trivial to compute!
(imagine, instead, a function that returns the center of mass
of the convex hull of an arbitrary, unordered set of 2D points
with that set of points being the "object" in question)

1. One approach is to implicitly compute the value of each (all!)
    function when the object is created/modified and update
    the cache at that time.

2. At the opposite extreme, defer the computation until it is
    explicitly requested (by a consumer) and cache it -- and ONLY
    it -- at that time.

Hybrid approaches would fill the middle ground.  E.g., compute
all such functions associated with the type when ANY of them
are requested; add a function ("cache_update()") used solely
for the side-effect of having it explicitly initialize each
of these values; create a function that operates on the entire
dataset; etc.

[I'm deliberately ignoring, for the time being, approaches
that impose an intermediary agent]

#1 is safest -- once initialized, all function values are available
in constant time, etc.  But, this comes at a high start-up cost
as the data is inaccessible until all of that work is done.

#2 gives the consumer control over where the resources (time)
should be spent -- if he isn't going to look at a particular
object (or a particular function of a particular instance of
an object), then why waste resources preparing that data?

Note that each approach also has consequences when the data
is loaded/backed up, etc.

#2 seems to be the best approach in that it exposes these
operations and lets me add a hook *outside* the database
that intentionally rebuilds this cached data based on
whatever policy seems right for each particular data set
(i.e., this could be used to implement #1 by running a
specific query "at startup" to explicitly create these values)

Thx,
--don

Back to comp.databases.postgresql | Previous | Next | Find similar | Unroll thread

Thread

"Priming" a base type's internal cache Don Y <this@isnotme.com> - 2012-06-28 11:06 -0700

csiph-web