On Tue, Sep 12, 2017 at 3:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I'd say that what you're proposing is the exact opposite of attacking > the problem at the root.
I agree. But if we're going to install a cache here, on a cycle-for-cycle basis, it's going to be hard to beat "caching" the knowledge that OIDs under 10000 are not domains. I don't find that to be an optimal solution, but I don't find dumping a bunch of caching code in there that involves writing more code to buy less performance to be superior, either. If we're going to install a point fix, I think there's much to be said for installing one that works well. If we want to revisit this more strategically, I think we should throw the whole idea of having the executor compute slot descriptors from the tlist out the window. Every executor node is walking over a linked list (uggh) of nodes and running not one but two fairly complex functions (exprType, exprTypmod) on each one. Then, each type OID has to be looked up by TupleDescInitEntry to get attlen/byval/align/storage/collation. Now, suppose we instead had an array of structures associated with each plan node, with each element containing <type OID, typmod, typlen, typbyval, typalign, typstorage, typcollation, smashed-to-base-type OID>. Then we wouldn't need syscache lookups to initialize the individual executor nodes or to build the RowDescription message, because we'd already have all the relevant bits in hand. Plus iterating over an array would probably be faster than iterating over a list. The downside is that we'd still need the tlists for other reasons, so plans would get bigger. But I don't think that's a huge problem if it makes them run faster. -- 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
