Jeevan Chalke <jeevan.cha...@enterprisedb.com> writes:
> It is observed that, when we have one remote (huge) table and one local
> (small) table and a join between them, then
> 1. If the column type is text, then we push the join qual to the remote
> server, so that we will have less rows to fetch, and thus execution time
> is very less.
> 2. If the column type is varchar, then we do not push the join qual to the
> remote server, resulting into large number of data fetch and thus
> execution time is very high.
Hmm ...
> Also given that RelabelType are just dummy wrapper for binary compatible
> types, can we simply set collation and state from its inner context instead
> on above check block.
I think you're blaming the wrong code; RelabelType is handled basically
the same as most other cases.
It strikes me that this function is really going about things the wrong
way. Rather than trying to determine the output collation per se, what
we ought to be asking is "does every operator in the proposed expression
have an input collation that can be traced to some foreign Var further
down in the expression"? That is, given the example in hand,
RelabelType(ForeignVar) = RelabelType(LocalVar)
the logic ought to be like "the ForeignVar has collation X, and that
bubbles up without change through the RelabelType, and then the equals
operator's inputcollation matches that, so accept it --- regardless of
where the other operand's collation came from exactly". The key point
is that we want to validate operator input collations, not output
collations, as having something to do with what the remote side would do.
This would represent a fairly significant rewrite of foreign_expr_walker's
collation logic; although I think the end result would be no more
complicated, possibly simpler, than it is now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
