Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Дата
Msg-id 3199563.1602527175@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I don't really understand how a version number helps. It's not like
> there is going to be a v2 that is in all ways better than v1. If there
> are different algorithms here, they are going to be customized for
> different needs.

Yeah, I agree --- a version number is the wrong way to think about this.
It's gonna be more like algorithm foo versus algorithm bar versus
algorithm baz, where each one is better for a specific set of use-cases.
Julien already noted the point about hashing object OIDs versus object
names; one can easily imagine disagreeing with pg_stat_statement's
choices about ignoring values of constants; other properties of statements
might be irrelevant for some use-cases; and so on.

I'm okay with moving pg_stat_statement's existing algorithm into core as
long as there's a way for extensions to override it.  With proper design,
that would allow extensions that do override it to coexist with
pg_stat_statements (thereby redefining the latter's idea of which
statements are "the same"), which is something that doesn't really work
nicely today.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Christensen
Дата:
Сообщение: Re: [PATCH] Add `truncate` option to subscription commands
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?