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 <klep...@svana.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
signature.asc
Description: Digital signature
