On Jul 11, 2011, at 11:45 AM, Jeff Davis <pg...@j-davis.com> wrote: > * ... It's also possible that > * we're acquiring a second or third lock type on a relation we have > * already locked using the fast-path, but for now we don't worry about > * that case either. > */ > > How common is that case? There are only 16 entries in the fast path lock > table, so it seems like it would frequently fill up. So, if there are > common code paths that acquire different weak locks on the same > relation, then we might commonly miss a fast-path opportunity.
Yeah, that might be worth some more thought. I haven't been that worried about overflow of the fast path table. If you are locking more than 16 relations at once, you probably have at least 5 tables in the query, maybe more - it depends in how many indexes you have, of course. My assumption has been that at that point you're going to spend enough time planning and executing the query that the lock manager will no longer be a major bottleneck. Of course, there might be cases where that isn't so. The trade-off here is that if we don't skip the fast path when we think the table's full, we slow down lock acquisitions 17 through infinity. I was reluctant to do that. I've been operating on the theory that the fast path should exist not because it's in general better (and thus we must be certain to use it whenever possible) but because it relieves unbearable pressure in specific problematic cases (and thus outside of those cases we just need it to stay out of the way). But it's possible that this is an overly simplistic mental model and not the best trade-off in practice. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
