On Thu, Aug 5, 2010 at 7:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> [ BackendRelFileNode patch ] > > One thing that I find rather distressing about this is the 25% bloat > in sizeof(SharedInvalidationMessage). Couldn't we avoid that? Is it > really necessary to *ever* send an SI message for a backend-local rel?
It can be dropped or unlinked by another backend, so, yes. > I agree that one needs to send relcache inval sometimes for temp rels, > but I don't see why each backend couldn't interpret that as a flush > on its own local version. The problem is that receipt of the inval message results in a call to smgrclosenode(), which has to look up the (Backend)RelFileNode in SMgrRelationHash. If the backend ID isn't present, we can't search the hash table efficiently. This is not only a problem for smgrclosenode(), either; that hash is used in a bunch of places, so changing the hash key isn't really an option. One possibility would be to have two separate shared-invalidation message types for smgr. One would indicate that a non-temporary relation was flushed, so the backend ID field is known to be -1 and we can search the hash quickly. The other would indicate that a temporary relation was flushed and you'd have to scan the whole hash table to find and flush all matching entries. That still doesn't sound great, though. Another thought I had was that if we could count on the backend ID to fit into an int16 we could fit it in to what's currently padding space. That would require rather dramatically lowering the maximum number of backends (currently INT_MAX/4), but it's a little hard to imagine that we can really support more than 32,767 simultaneous backends anyway. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
