Re: [HACKERS] JIT & function naming - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] JIT & function naming
Date
Msg-id 20170902235955.6b6x23tdbyp7k6ix@alap3.anarazel.de
Whole thread Raw
In response to [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] JIT & function naming  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Re: [HACKERS] JIT & function naming  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Function to move the position of a replication slot
Next
From: Amit Kapila
Date:
Subject: [HACKERS] Fix warnings and typo in dshash