On Sat, Dec 17, 2011 at 12:25 PM Marti Raudsepp <ma...@juffo.org> wrote: > Ah, one more trick for testing this patch: if you build with > -DDEBUG_CACHEEXPR=1 then EXPLAIN VERBOSE displays cached > subexpressions between a CACHE[...] marker.
Unless I missed something, this 2011 thread is the latest one about this patch, and the patch was never applied, and nothing similar ever got done either. Is that correct? If so, was there any particular reason why this wasn't judged to be a good idea, or did it just not get enough attention? This was on my mind today because of a FDW pushdown question that came up. Someone observed that a predicate of the form foreign_table_column pushable_operator hairy_but_stable_expression is not pushed down. In theory, it could be: just compute the value of hairy_but_stable_expression locally, and then send the result across. The trick is that it requires identifying a maximal stable subexpression. In this case, the whole expression isn't stable, because every row will provide a different value for foreign_table_column, but the subexpression which is the right child of the toplevel OpExpr is stable. Identifying that seems like it could be somewhat expensive and I seem to vaguely recall some discussion of that issue, but I think not on this thread. But if this patch - or some other one - happened to inject a CacheExpr at the right place in the plan tree, then postgres_fdw could leverage that existing determination in a pretty straightforward way, precomputing the cached value locally and then pushing the clause if otherwise safe. That's also just a fringe benefit. Marti's test results show significant speedup in all-local cases, which seem likely to benefit a pretty broad class of queries. We'd probably have to give some thought to how the technique would work with Andres's rewrite of expression evaluation, but I imagine that's a solvable problem. -- Robert Haas EDB: http://www.enterprisedb.com
