Re: Increasing the length of

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Increasing the length of
Date: 2004-11-10 21:32:47
Message-ID: 1100122367.4442.607.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2004-11-10 21:48:59 Re: Increasing the length of
Previous Message Tom Lane 2004-11-10 20:26:34 Re: CREATE or REPLACE function pg_catalog.*