Re: notify duplicate elimination performance

Tom Lane schrieb:
> Hardy Falk <hardy(dot)falk(at)blue-cable(dot)de> writes:
>>> Well, you didn't add any code, so it's hard to say... Simple ways of
>>> doing what I think you describe will remove the queue's order. Do you
>>> preserve the ordering guarantees?
>
>> Yes, the order is preserved.
>> I didn't remove the the original list code.
>> The tree is just an additional access path.
>
> It seems likely that this approach would be a net loss for small numbers
> of notify events (which is surely the common case). Have you done any
> measurements of the performance tradeoff?
>
> regards, tom lane
>
>
I can easily keep the tail test. This avoids the hash computation in a
common case. The tree search compares only uint32 values, this should be
quite fast. Even a degenerate tree is no worse than the list. Im my
first tests I didn't use murmurhash, a select
pg_notify('alasys',format('Hello %s',x) from generate_series(1,1000000)
as x triggered this worst case. With murmurhash2 the average search
depth for 10^6 entries is 24.57.

I am about to prepare a patch, should I do some performance tests with
rtdsc first?