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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
