Re: domain type smashing is expensive

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The trick here is that I don't think we want to change the returned column
>> types for queries that are not being sent to a client. The parser and
>> planner aren't really aware of that context ATM. Maybe we could make them
>> so?

> I guess it depends on whether that context is mutable. Can I Parse a
> query to create a prepared statement, then use that from a stored
> procedure? If so, then it's not firmly known at plan time what the
> execution context will be.

Um, good point; I'm pretty sure that we don't distinguish. This may
well be the reason it's done like this right now.

>> I wonder if it'd help to put some kind of bespoke cache into getBaseType.
>> We've done that elsewhere, eg operator lookup.

> That might be a possibility, although I feel like it's likely to be
> substantially less effective than the quick hack, and it's not really
> attacking the problem at the root anyway.

I'd say that what you're proposing is the exact opposite of attacking
the problem at the root.

regards, tom lane