Re: pg_stat_statments queryid

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_stat_statments queryid
Дата
Msg-id 20454.1337871963@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_stat_statments queryid  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg_stat_statments queryid  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: pg_stat_statments queryid  (Peter Geoghegan <peter@2ndquadrant.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, May 24, 2012 at 10:26 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> But I think this explanation is enough to convince me that it might be
> worthwhile:

>> What I'd like to be able to do is aggregate this information over time
>> and/or across standbys in a cluster, as queries are evicted and
>> subsequently re-entered into pg_stat_statement's shared hash table.

It appears to me that the above ...

>> ... I'd also credit our users with being
>> discerning enough to realise that they should not jump to the
>> conclusion that the value will be stable according to any particular
>> standard.

... is in direct contradiction to this.  The proposed usage absolutely
requires that the hash be stable "over time and/or across standbys".
I do not want to promise that it's stable over any timeframe longer than
a server reboot.  Aside from the OID dependence problem, we might well
change the way the hash is calculated in minor releases, for example by
adding or removing struct fields.
        regards, tom lane


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

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: [RFC] Interface of Row Level Security
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [9.2] crash on regex