Robert Haas <robertmh...@gmail.com> writes:
> On short-running queries that return a lot of columns,
> SendRowDescriptionMessage's calls to getBaseTypeAndTypmod() are a
> noticeable expense.
Yeah, I was never very happy with the way that the original domain
patch dealt with that. I think you're not even focusing on the
worst part, which is all the getBaseType calls in the parser.
I do not have a good idea about how to get rid of them though.
> + if (typid < FirstBootstrapObjectId)
> + break;
I'm really unwilling to buy into an assumption that we'll never
have any built-in domains just to support such a crock as this.
> 1. Revisit the decision to smash domain types to base types here.
> That change was made by Tom Lane back in 2003
> (d9b679c13a820eb7b464a1eeb1f177c3fea13ece) but the commit message only
> says *that* we decided to do it, not *why* we decided to do it, and
> the one-line comment added by that commit doesn't do any better.
You'd need to dig around in the archives from around that time. But
my hazy recollection is that the argument was that clients would be
much more likely to know what to do with a built-in type than with
some domain over it. psql, for example, knows about right-justifying
the built-in numeric types, but it'd fail to do so for domains.
> 2. Precompute the list of types to be sent to the client during
> planning instead of during execution. The point of prepared
> statements is supposed to be to do as much of the work as possible at
> prepare time so that bind/execute is as fast as possible, but we're
> not really adhering to that design philosophy here. However, I don't
> have a clear idea of exactly how to do that.
That'd help for prepared statements, but not for simple query execution.
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? But it still seems like a kluge that is only addressing a small part
of the domain-smashing issue.
I wonder if it'd help to put some kind of bespoke cache into getBaseType.
We've done that elsewhere, eg operator lookup.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
