Hi, On 2017-08-31 23:41:31 -0700, Andres Freund wrote: > I previously had an early prototype of JITing [1] expression evaluation > and tuple deforming. I've since then worked a lot on this. > > Here's an initial, not really pretty but functional, submission.
One of the things I'm not really happy about yet is the naming of the generated functions. Those primarily matter when doing profiling, where the function name will show up when the profiler supports JIT stuff (e.g. with a patch I proposed to LLVM that emits perf compatible output, there's also existing LLVM support for a profiler by intel and oprofile). Currently there's essentially a per EState counter and the generated functions get named deform$n and evalexpr$n. That allows for profiling of a single query, because different compiled expressions are disambiguated. It even allows to run the same query over and over, still giving meaningful results. But it breaks down when running multiple queries while profiling - evalexpr0 can mean something entirely different for different queries. The best idea I have so far would be to name queries like evalexpr_$fingerprint_$n, but for that we'd need fingerprinting support outside of pg_stat_statement, which seems painful-ish. Perhaps somebody has a better idea? Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
