On Wed, 2004-11-10 at 20:25, Jan Wieck wrote:
> On 11/8/2004 5:32 PM, Tom Lane wrote:
>
> > Another relevant question is why you are expecting to get this
> > information through pgstats and not by looking in the postmaster log.
>
> The pgstats were originally designed to give "hints" for tuning. That's
> why they cover cache hits vs. misses per table and numbers that can be
> used to point out missing as well as obsolete indexes. That was what led
> to the design of the pgstats file, the UDP communication and those fixed
> sizes. The goal was to let it have as little impact on the server
> performance as possible. The whole "current query" stuff was added later
> on request.
>
OK, and thanks for writing it.
Evolution is a wonderful thing... our original design point was slightly
away from where we are now.
> In my opinion it is quite pointless to attempt to transmit the last byte
> of every single query sent to the backend, when all you can get out of
> that view is a random query every 500 milliseconds.
If you are certain you have no queries whose text is > 1 KB, or you have
no SQL that lasts > a few seconds, then increasing the UDP limit would
just be a painful waste, I agree.
My intention was towards a data warehouse situation, and my comments are
only relevant in that context. Possibly 25+% of the user base use this
style of processing. In that case, I expect queries to run for minutes
or hours.
What are the alternatives when a query is still running when you return
from lunch? Kill it? Hope? These rogue queries can be a problem, using
up much of the capacity of the system for hours.
Many such queries are generated by applications and hard to recreate.
The server is running it, so we should be able to access the SQL and
diagnose.
--
Best Regards, Simon Riggs
