On 31.10.2010 16:39, Tom Lane wrote:
Peter Eisentraut<pete...@gmx.net> writes:
Here's a big patch to avoid passing around type OID + typmod (+
collation) separately all over the place. Instead, there is a new
struct TypeInfo that contains these fields, and only a pointer is passed
around.
Some stuff in here (or not in here) is probably a matter of taste, as
with any such large refactoring, but in general you can see that it
saves a lot of notational overhead.
I can't escape the feeling that the principal result of this patch will
be a huge increase in palloc overhead. It's certainly going to double
the number of nodes needed for common structures like Vars, Consts,
OpExprs, and FuncExprs. Have you checked the effects on
parsing/planning runtime?
Yeah, that was my first impression too. I assumed that TypeInfo would be
embedded in other structs directly, rather than a pointer and palloc.
Something like:
/*
* TypeInfo - encapsulates type information
*/
typedef struct TypeInfo
{
Oid typeid;
int32 typmod;
} TypeInfo;
...
typedef struct Const
{
Expr xpr;
- Oid consttype; /* pg_type OID
of the constant's datatype */
- int32 consttypmod; /* typmod value, if any */
+ TypeInfo consttype; /* type information of the
constant's datatype */
int constlen; /* typlen of
the constant's datatype */
Datum constvalue; /* the constant's value */
Also, maybe I missed this, but do we have a clear understanding of
how collation markers propagate through operations? I seem to remember
that way back when, we were thinking of it as a runtime-determined
property --- for which, managing it like typmod would be quite useless.
This whole approach seems to depend on the assumption that collation
markers can be set at parse time, which isn't something I'm sure works.
Surely you have to be able to determine the collations at parse time,
just like any other type information. I don't see how it could possible
work at runtime. The collations involved affect the plan, whether you
have to sort at various stages, for example.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
