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
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 |