On 09/03/2017 02:59 AM, Andres Freund wrote:
> 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?
As far as I understand we do not need precise fingerprint.
So may be just calculate some lightweight fingerprint?
For example take query text (es_sourceText from EText), replace all non-alphanumeric characters spaces with '_' and
takefirst N (16?) characters of the result?
It seems to me that in most cases it will help to identify the query...
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
