Re: notify duplicate elimination performance

Tom Lane schrieb:
> Hardy Falk <hardy.falk@blue-cable.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?