Hannu Krosing <hannu@krosing.net> writes:
> In that case we have to decide for the user for which case we optimize
> and give user suboptimal performanse for the _other_ case.
If we're gonna do it, I'd just do it; that code is hairy enough already
without trying to support multiple, fundamentally different operating
modes.
An advantage of switching is that the insert, update, and delete cases
would all become truly alike to inval.c, thus making that module simpler
instea of more complex. I find this attractive.
One thing I realized after my last message on the subject is that the
cross-backend SI messages do not carry the actual key values of the
tuple being inserted/deleted/updated. What they do carry is a hash
index, which is presently used only to speed up the search for matching
cache entries to be purged. What we'd have to do with negative cache
entries is (for an insert) purge *all* negative cache entries on that
hash chain, since we couldn't tell exactly which if any correspond to
the keys of the inserted tuple. I don't think this is a big problem;
hopefully each individual hash chain is short and so not very many
negative entries would become collateral casualties. But it is another
potential source of inefficiency.
regards, tom lane
