Re: compute_query_id and pg_stat_statements

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > There's a ridiculously simple option here which is: drop the idea that
> > we support an extension redefining the query id and then just make it
> > on/off with the default to be 'on'.
>
> I do not think that defaulting it to 'on' is acceptable unless you can
> show that the added overhead is negligible. IIUC the measurements that
> have been done show the opposite.

Ah, right, it had only been done before when pg_stat_statements was
loaded.. In which case, it seems like we should:

a) go back to that

b) if someone wants an alternative query ID, tell them to add it to
pg_stat_statements and make it configurable *there*

c) Have pg_stat_statements provide another function/view/etc that folks
can use to get a queryid for an ongoing query ..?

d) Maybe come up with a way for extensions, generically, to make a value
available to log_line_prefix? That could be pretty interesting.

Or just accept that this is a bit hokey with the 'auto' approach. I get
Bruce has concerns about it but I'm not convinced that it's actually all
that bad to go with that.

Thanks,

Stephen