Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty

On Thu, Mar 10, 2011 at 10:34:00AM -0500, Tom Lane wrote:
> Hmm. That suggests a third solution: revert the addition of *all* the
> collid fields except the ones that represent collation-to-apply-during-
> function-execution. (So they'd still be there in FuncExpr/OpExpr, but
> not most other places.) Then we'd have to dig down more deeply in the
> expression tree during select_common_collation, but we'd save space
> and avoid confusion over the meaning of the fields.

Yeah, it occurred to me if you made each collate clause translate to a
collate node that changes the collation, a bit like casts, then the
parse nodes don't need to know about collation at all.

> I suspect this is probably not a good idea because of the added cost in
> select_common_collation: aside from probably needing more syscache
> lookups, there's a potential for worse-than-linear cost behavior if we
> have to repeatedly dig through a deep expression tree to find out
> collations. We had a similar case in the past [ checks archives ... see
> http://archives.postgresql.org/pgsql-performance/2005-06/msg00075.php
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=ba4200246
> ] so I'm hesitant to go down that road again. Still, I'll throw it out
> for comment.

Two things can make a difference here:

- If you knew which operators/functions cared about the collation, the
cost could be manageable. We don't so...

- ISTM that in theory any algorithm that is defined by recursion at
each node, should be calculatable via a single pass of the tree by
something like parse_expr. That's essentially what the variables are
doing in the Expr nodes, though whether you need one or two is
ofcourse another question.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle