Re: listen/notify argument (old topic revisited) - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: listen/notify argument (old topic revisited)
Date
Msg-id 1025713119.23475.89.camel@taru.tm.ee
Whole thread Raw
In response to Re: listen/notify argument (old topic revisited)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 2002-07-03 at 16:30, Tom Lane wrote:
> 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. 

It may become large if we will have an implementation which can cope
well with lage volumes :)

> I think I'd lean towards minimizing the time spent holding the
> shared lock, instead.

In case you are waiting for just one message out of 1000 it may still be
faster to do selective copying.

It is possible that 1000 strcmp's + 1000 pointer traversals are faster
than one big memcpy, no ?

> But it's a judgment call.

If we have a clean C interface + separate PG binding we may write
several different modules for different scenarios and let the user
choose (even at startup time) - code optimized for messages that
everybody wants is bound to be suboptimal for case when they only want 1
out of 1000 messages. Same for different message sizes.

-------------
Hannu





pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: listen/notify argument (old topic revisited)
Next
From: nconway@klamath.dyndns.org (Neil Conway)
Date:
Subject: Re: listen/notify argument (old topic revisited)