Re: Assert in pg_stat_statements
От | Satoshi Nagayasu |
---|---|
Тема | Re: Assert in pg_stat_statements |
Дата | |
Msg-id | CAA8soze0Syf-1zPB9Y-txzFwH7ZO32ZaaEQ3y1p_bYcWKhyucw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assert in pg_stat_statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2015-08-10 2:23 GMT+09:00 Tom Lane <tgl@sss.pgh.pa.us>: > Robert Haas <robertmhaas@gmail.com> writes: >> I'm not too excited about supporting the use case where there are two >> people using queryId but it just so happens that they always set >> exactly the same value. That seems like a weird setup. Wouldn't that >> mean both modules were applying the same jumble algorithm, and >> therefore you're doing the work of computing the jumble twice per >> query? > > Not only that, but you'd need to keep the two modules in sync, which > would be one of the greatest recipes for bugs we've thought of yet. > > If there's actually a use case for that sort of thing, I would vote > for moving the jumble-calculation code into core and making both of > the interested extensions do > > /* Calculate query hash if it's not been done yet */ > if (query->queryId == 0) > calculate_query_hash(query); I vote for this too. Jumble-calculation is the smartest way to identify query groups, so several modules can take advantages of it if in the core. Regards, -- Satoshi Nagayasu <snaga@uptime.jp>
В списке pgsql-hackers по дате отправления: