Re: listen/notify argument (old topic revisited)

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jeff Davis <list-pgsql-hackers(at)empires(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: listen/notify argument (old topic revisited)
Date: 2002-07-03 16:18:39
Message-ID: 1025713119.23475.89.camel@taru.tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2002-07-03 16:21:23 UNIQUE predicate
Previous Message Bruce Momjian 2002-07-03 16:18:12 Re: BETWEEN Node & DROP COLUMN