Re: Patch: add timing of buffer I/O requests - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Patch: add timing of buffer I/O requests
Date
Msg-id CAEYLb_UBUDst5RkaxR=KT563oJydp=gtRCsfxjsQeBERSa5tEA@mail.gmail.com
Whole thread Raw
In response to Re: Patch: add timing of buffer I/O requests  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch: add timing of buffer I/O requests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11 April 2012 00:35, Robert Haas <robertmhaas@gmail.com> wrote:
> If people need something like that, couldn't they create it by hashing
> the normalized query text with an arbitrary algorithm?

That supposes that the normalised query text is perfectly stable. It
may well not be, particularly for things like ad-hoc queries or
queries generated by ORMs, across database clusters and over long
periods of time - you're basically throwing the benefit of all of that
intelligent normalisation out of the window, because it's pretty close
to free to expose it. What if a developer tweaks an alias in the
application for clarity? Also, as you point out, it has additional
utility in advertising when a collision has happened, and setting the
user's expectations appropriately. I assume that collisions are very
rare, but when they do happen, this gives you a fighting chance of
noticing them.

As Tom points out, the query hash will vary according to platform
specific characteristics, including endianness, and will require OIDs
are the same on every node. However, it is still going to be useful in
clusters that use streaming replication, though not a third party
trigger based replication system for example, because streaming
replication does of course require that those factors (and rather a
lot more) will be identical across the cluster anyway. Realistically,
I'd expect a large majority of people interested in this feature to
only want to use it with streaming replication anyway.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_tablespace_location() error message
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade incorrectly equates pg_default and database tablespace