Our approach is referred to as plan-per-tuple. The primary focus being on large objects used as predicate-based terms when a non co-located join is involved in the query. But can also be applicable in non co-located join scenarios also. The execution engine can choose from among N! resource optimization strategies; where N represents system manageable resources. In our case, the N resources are: (i) interconnect saturation levels, (ii)available physical memory, (iii) CPU utilization, and (iv) available disk spool space percentages. However, this technique can be applied to any system resources being managed. The optimizer search space does not include these N! resource optimizationstrategies per'se, these are execution engine run-time optimization strategies. When the optimizer identifies expensive, or more importantly a high variant, user- defined function in the predicate (via collected statistics), then the optimizer can generate plans that incorporate plan-per-tuple optimization for that particular compiled query. When executing the plan, a different execution strategy can be used per tuple; the available execution choices do not necessarily equal N! Wedescribe when such an overhead for run-time selection is acceptable.