Excerpts from Simon Riggs's message of mar jul 26 14:11:19 -0400 2011:
> Let me ask a few questions to stimulate a different solution
>
> * Can we do this using an active technique (e.g. signals) rather than
> a passive one (reading a counter?)
Signals are already in use for special cases (queue is full), and I
think going through the kernel to achieve much more will lower
performance significantly.
> * Can we partition the sinval lock, so we have multiple copies? That
> increases the task for those who trigger an invalidation, but will
> relieve the pressure for most readers.
Not sure there's a way to meaningfully partition the queue. In any
case, I think the problem being dealt with here is how to update the
read heads of the queue, not its contents.
> * Can we put the sinval info in a different place? e.g. inside each
> lock partition.
I don't think you can relate sinval messages to particular locks, which
would make this infeasible. I think this bit is directly related to the
point above.
> * Why do we have a different mechanism for cache invalidation
> internally (sinval) to the one we offer externally (LISTEN/NOTIFY)?
> Why don't we have just one?
Performance. Not sure there are other reasons as well; but just this
one is significant enough.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
