Re: Increasing the length of
От
Simon Riggs
Тема
Re: Increasing the length of
Дата
Msg-id
1100122367.4442.607.camel@localhost.localdomain
Ответ на
Список
Дерево обсуждения
Increasing the length of pg_stat_activity.current_query... Sean Chittenden <sean@chittenden.org>
Re: Increasing the length of pg_stat_activity.current_query... Tom Lane <tgl@sss.pgh.pa.us>
Re: Increasing the length of Simon Riggs <simon@2ndquadrant.com>
Re: Increasing the length of pg_stat_activity.current_query... Tom Lane <tgl@sss.pgh.pa.us>
Re: Increasing the length of pg_stat_activity.current_query... Greg Stark <gsstark@mit.edu>
Re: Increasing the length of Simon Riggs <simon@2ndquadrant.com>
Re: Increasing the length of pg_stat_activity.current_query... Greg Stark <gsstark@mit.edu>
Re: Increasing the length of pg_stat_activity.current_query... Tom Lane <tgl@sss.pgh.pa.us>
Re: Increasing the length of pg_stat_activity.current_query... Gaetano Mendola <mendola@bigfoot.com>
Re: Increasing the length of pg_stat_activity.current_query... Greg Stark <gsstark@mit.edu>
Re: Increasing the length of pg_stat_activity.current_query... Tom Lane <tgl@sss.pgh.pa.us>
Re: Increasing the length of pg_stat_activity.current_query... Greg Stark <gsstark@mit.edu>
Re: Increasing the length of pg_stat_activity.current_query... Tom Lane <tgl@sss.pgh.pa.us>
Re: Increasing the length of Simon Riggs <simon@2ndquadrant.com>
Re: Increasing the length of Richard Huxton <dev@archonet.com>
Re: Increasing the length of Simon Riggs <simon@2ndquadrant.com>
Re: Increasing the length of Andrew Sullivan <ajs@crankycanuck.ca>
Re: Increasing the length of Simon Riggs <simon@2ndquadrant.com>
Re: Increasing the length of Bruce Momjian <pgman@candle.pha.pa.us>
Re: Increasing the length of Andrew Sullivan <ajs@crankycanuck.ca>
Re: Increasing the length of Robert Treat <xzilla@users.sourceforge.net>
Re: Increasing the length of Andrew Sullivan <ajs@crankycanuck.ca>
Re: Increasing the length of pg_stat_activity.current_query... Oliver Jowett <oliver@opencloud.com>
Re: Increasing the length of pg_stat_activity.current_query... Jan Wieck <JanWieck@Yahoo.com>
Re: Increasing the length of Simon Riggs <simon@2ndquadrant.com>
Re: Increasing the length of pg_stat_activity.current_query... Greg Stark <gsstark@mit.edu>
Re: Increasing the length of pg_stat_activity.current_query... Greg Stark <gsstark@mit.edu>
Re: Increasing the length of pg_stat_activity.current_query... Sean Chittenden <sean@chittenden.org>
Re: Increasing the length of pg_stat_activity.current_query... Tom Lane <tgl@sss.pgh.pa.us>
Re: Increasing the length of pg_stat_activity.current_query... Sean Chittenden <sean@chittenden.org>
Re: Increasing the length of pg_stat_activity.current_query... Tom Lane <tgl@sss.pgh.pa.us>
Re: Increasing the length of pg_stat_activity.current_query... Greg Stark <gsstark@mit.edu>
Re: Increasing the length of pg_stat_activity.current_query... Bruce Momjian <pgman@candle.pha.pa.us>
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
В списке pgsql-hackers по дате отправления