You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Faster expression evaluation and targetlist projection.
This replaces the old, recursive tree-walk based evaluation, withnon-recursive, opcode dispatch based, expression evaluation.Projection is now implemented as part of expression evaluation.This both leads to significant performance improvements, and makesfuture just-in-time compilation of expressions easier.The speed gains primarily come from:- non-recursive implementation reduces stack usage / overhead- simple sub-expressions are implemented with a single jump, without function calls- sharing some state between different sub-expressions- reduced amount of indirect/hard to predict memory accesses by laying out operation metadata sequentially; including the avoidance of nearly all of the previously used linked lists- more code has been moved to expression initialization, avoiding constant re-checks at evaluation timeFuture just-in-time compilation (JIT) has become easier, asdemonstrated by released patches intended to be merged in a laterrelease, for primarily two reasons: Firstly, due to a stricter splitbetween expression initialization and evaluation, less code has to behandled by the JIT. Secondly, due to the non-recursive nature of thegenerated "instructions", less performance-critical code-paths caneasily be shared between interpreted and compiled evaluation.The new framework allows for significant future optimizations. E.g.:- basic infrastructure for to later reduce the per executor-startup overhead of expression evaluation, by caching state in prepared statements. That'd be helpful in OLTPish scenarios where initialization overhead is measurable.- optimizing the generated "code". A number of proposals for potential work has already been made.- optimizing the interpreter. Similarly a number of proposals have been made here too.The move of logic into the expression initialization step leads to somebackward-incompatible changes:- Function permission checks are now done during expression initialization, whereas previously they were done during execution. In edge cases this can lead to errors being raised that previously wouldn't have been, e.g. a NULL array being coerced to a different array type previously didn't perform checks.- The set of domain constraints to be checked, is now evaluated once during expression initialization, previously it was re-built every time a domain check was evaluated. For normal queries this doesn't change much, but e.g. for plpgsql functions, which caches ExprStates, the old set could stick around longer. The behavior around might still change.Author: Andres Freund, with significant changes by Tom Lane,changes by Heikki LinnakangasReviewed-By: Tom Lane, Heikki LinnakangasDiscussion:https://postgr.es/m/20161206034955.bh33paeralxbtluv@alap3.anarazel.de