Greg Copeland <[EMAIL PROTECTED]> writes:
> What if we used a combination of the two approaches? That is, when an
> overflow occurs, overflow into a table?
I think this is a really bad idea.
The major problem with it is that the overflow path would be complex,
infrequently exercised, and therefore almost inevitably buggy. (Look
at all the problems we had for so long with SI overflow response. I'd
still not like to have to swear there are none left.)
Also, I do not think you could get away with merging listen/notify with
the system cache inval mechanism if you wanted to have table overflow for
listen/notify. SI is too low level --- to point out just one problem,
a new backend's access to the SI message queue has to be initialized
long before we are ready to do any table access. So you'd be requiring
dedicated shared memory space just for listen/notify. That's a hard
sell in my book.
> That way, nothing is lost and spurious random events don't have to
> occur.
I think this argument is spurious. Almost any client-side caching
arrangement is going to have cases where it's best to issue a "flush
everything" kind of event rather than expend the effort to keep track
of exactly what has to be invalidated by particular kinds of changes.
As long as such changes are infrequent, you have better performance
and better reliability by not trying to do the extra bookkeeping for
exact invalidation. Why shouldn't the signal transport mechanism
be able to do the same thing?
Also, the notion that the NOTIFY mechanism can't be lossy misses the
fact that you've got a perfectly good non-lossy mechanism at hand
already: user tables. The traditional way of using NOTIFY has been
to stick the important data into tables and use NOTIFY simply to
cue listeners to look in those tables. I don't foresee this changing;
it'll simply be possible to give somewhat finer-grain notification of
what/where to look. I don't think that forcing NOTIFY to have the
same kinds of semantics as SQL tables do is the right design approach.
IMHO the only reason NOTIFY exists at all is to provide a simpler,
higher-performance communication pathway than you can get with tables.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
