Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
От | Bruce Momjian |
---|---|
Тема | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
Дата | |
Msg-id | 20201014142523.GA9415@momjian.us обсуждение исходный текст |
Ответ на | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
|
Список | pgsql-hackers |
On Wed, Oct 14, 2020 at 10:21:24PM +0800, Julien Rouhaud wrote: > On Wed, Oct 14, 2020 at 10:09 PM Bruce Momjian <bruce@momjian.us> wrote: > > > > OK, I came up with the hash idea only to address one of your concerns > > > > about mismatched hashes for algorithm improvements/changes. Seems we > > > > might as well just document that cross-version hashes are different. > > > > > > Ok, so I tried to implement what seems to be the consensus. First > > > attached patch moves the current pgss queryid computation in core, > > > with a new compute_queryid GUC (on/off). One thing I don't really > > > > Why would someone turn compute_queryid off? Overhead? > > Yes, or possibly to use a different algorithm. Is there a measureable overhead when this is turned on, since it is off by default and maybe should default to on. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
В списке pgsql-hackers по дате отправления: