There are two outstanding patches for SSI which involve questions about modularity. In particular, they involve calls to predicate locking and conflict detection from executor source files rather than AM source files (where most such calls exist). (1) Dan submitted this patch: http://archives.postgresql.org/message-id/20110622045850.gn83...@csail.mit.edu which is a very safe and very simple patch to improve performance on sequential heap scans at the serializable transaction isolation level. The location of the code being modified raised questions about modularity. There is a reasonably clear place to which it could be moved in the heap AM, but because it would acquire a predicate lock during node setup, it would get a lock on the heap even if the node was never used, which could be a performance regression in some cases. (2) In reviewing the above, Heikki noticed that there was a second place in the executor that SSI calls were needed but missing. I submitted a patch here: http://archives.postgresql.org/message-id/4e07550f020000250003e...@gw.wicourts.gov I wonder, though, whether the section of code which I needed to modify should be moved to a new function in heapam.c on modularity grounds. If these two places were moved, there would be no SSI calls from any source file in the executor subdirectory. Should these be moved before beta3? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
