Re: domain type smashing is expensive

On Tue, Sep 12, 2017 at 3:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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