Re: type info refactoring

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: type info refactoring
Дата
Msg-id 4CCD9E4D.1080602@enterprisedb.com
обсуждение исходный текст
Ответ на Re: type info refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: type info refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: type info refactoring  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On 31.10.2010 16:39, Tom Lane wrote:
> Peter Eisentraut<peter_e@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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: ALTER OBJECT any_name SET SCHEMA name
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: ALTER OBJECT any_name SET SCHEMA name