Re: type info refactoring

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: type info refactoring
Date: 2010-10-31 16:50:21
Message-ID: 4CCD9E4D.1080602@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31.10.2010 16:39, Tom Lane wrote:
> Peter Eisentraut<peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-10-31 16:59:45 Re: ALTER OBJECT any_name SET SCHEMA name
Previous Message Dimitri Fontaine 2010-10-31 16:45:53 Re: ALTER OBJECT any_name SET SCHEMA name