Andres Freund <and...@anarazel.de> writes:
> 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.
Yeah. Why not just use a static counter to give successive unique IDs
to each query that gets JIT-compiled? Then the function names would
be like deform_$querynumber_$subexprnumber.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
