On Tue, Oct 25, 2011 at 11:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Even given your recent changes to reduce the overhead of checking for > sinval messages, I'm not sure that it'd be practical to move the sinval > message processing to just-before-we-look-up-a-cache-entry.
Wait a minute: I'm confused. What's at issue here, at least AIUI, is taking a TOAST pointer and fetching the corresponding value. But that must involve reading from the TOAST table, and our usual paradigm for reading from system catalogs is (1) take AccessShareLock, (2) read the relevant rows, (3) release AccessShareLock. If we're doing that here, then AcceptInvalidationMessages() is already getting called. If we're not, this seems horribly unsafe; aside from the current bug, somebody could rewrite the table in the interim. > Right now, > we do AcceptInvalidationMessages basically once per table per query > (or maybe it's twice or so, but anyway a very small multiplier on that). > If we try to do it every time through SearchSysCache, we are probably > talking two to three orders of magnitude more checks, which ISTM is > certain to push the sinval queue back up to the top of the heap for > contention. I think we've pretty much got the *contention* licked, barring an increase in the number of things that generate sinval messages, but calling it too often will still be slow, of course. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
