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 20201012141445.GA24889@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?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Oct 12, 2020 at 04:20:05PM +0800, Julien Rouhaud wrote:
> But there are many people that aren't happy with the current hashing
> approach.  If we're going to move the computation in core, shouldn't
> we listen to their complaints and let them pay some probably quite
> high overhead to base the hash on name and/or fully qualified name
> rather than OID?
> For instance people using logical replication to upgrade to a newer
> version may want to easily compare query performance on the new
> version, or people with multi-tenant databases may want to ignore the
> schema name to keep a low number of different queryid.

Well, we have to consider how complex the user interface has to be to
allow more flexibility.  We don't need to allow every option a user will
want.

With a version number, we have the ability to improve the algorithm or
add customization, but for the first use, we are probably better off
keeping it simple.

-- 
  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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [HACKERS] Custom compression methods
Следующее
От: Pavel Stehule
Дата:
Сообщение: broken logic of simple_eval_resowner after CALL and COMMIT inside procedure