On 2017-09-03 10:11:37 -0400, Tom Lane wrote: > 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.
That works, but unfortunately it doesn't keep the names the same over reruns. So if you rerun the query inside the same session - a quite reasonable thing to get more accurate profiles - the names in the profile will change. That makes it quite hard to compare profiles, especially when a single execution of the query is too quick to see something meaningful. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers