On Sat, Dec 29, 2012 at 6:37 PM, Peter Geoghegan <pe...@2ndquadrant.com> wrote: > On 29 December 2012 12:21, Daniel Farina <drfar...@acm.org> wrote: >> These were not express goals of the patch, but so long as you are >> inviting features, attached is a bonus patch that exposes the queryid >> and also the notion of a "statistics session" that is re-rolled >> whenever the stats file could not be read or the stats are reset, able >> to fully explain all obvious causes of retrograde motion in >> statistics. It too is cumulative, so it includes the under-estimation >> field. > > Cool. > > I had a thought about Tom's objection to exposing the hash value. I > would like to propose a compromise between exposing the hash value and > not doing so at all.
As I recall, the gist of this objection had to do with a false sense of stability of the hash value, and the desire to enforce the ability to alter it. Here's an option: xor the hash value with the 'statistics session id', so it's *known* to be unstable between sessions. That gets you continuity in the common case and sound deprecation in the less-common cases (crashes, format upgrades, stat resetting). A change in hash function should also then necessitate changing the stat file header. Another more minor issue is the hard-wiring of the precision of the id. For that reason, I have thought it reasonable to expose this as a string also. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
