Re: listen/notify argument (old topic revisited)

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> There could a little more smartness here to avoid unneccessary copying
> (not just storing) of not-listened-to data.

Yeah, I was wondering about that too.

> I guess that depending on the circumstances this can be either faster or
> slower than copying them all in one memmove.

The more interesting question is whether it's better to hold the read
lock on the shared buffer for the minimum possible amount of time; if
so, we'd be better off to pull the data from the buffer as quickly as
possible and then sort it later. Determining whether we are interested
in a particular notify name will probably take a probe into a (local)
hashtable, so it won't be super-quick. However, I think we could
arrange for readers to use a sharable lock on the buffer, so having them
expend that processing while holding the read lock might be acceptable.

My guess is that the actual volume of data going through the notify
mechanism isn't going to be all that large, and so avoiding one memcpy
step for it isn't going to be all that exciting. I think I'd lean
towards minimizing the time spent holding the shared lock, instead.
But it's a judgment call.

regards, tom lane