On Mon, Feb 25, 2013 at 10:22 PM, Greg Stark st...@mit.edu wrote:
On Mon, Feb 25, 2013 at 8:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby j...@nasby.net wrote:
We actually do that in our application and have discovered that random
sampling can end
On 2/26/13 11:19 AM, Robert Haas wrote:
On Mon, Feb 25, 2013 at 10:22 PM, Greg Stark st...@mit.edu wrote:
On Mon, Feb 25, 2013 at 8:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby j...@nasby.net wrote:
We actually do that in our application and have
On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby j...@nasby.net wrote:
We actually do that in our application and have discovered that random
sampling can end up significantly skewing your data.
/me blinks.
How so?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Mon, Feb 25, 2013 at 8:26 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby j...@nasby.net wrote:
We actually do that in our application and have discovered that random
sampling can end up significantly skewing your data.
/me blinks.
How so?
Sorry for the late reply, but I think I can add some ideas here...
On 11/21/12 5:33 PM, Gavin Flower wrote:
On 22/11/12 12:15, Greg Smith wrote:
On 11/8/12 2:16 PM, Josh Berkus wrote:
Also, logging only the long-running queries is less useful than people
on this list seem to think. When I'm
Greg Smith escribió:
If I could just turn off logging just during those
periods--basically, throwing them away only when some output rate
throttled component hit its limit--I could still find them in the
data collected the rest of the time. There are some types of
problems that also only
On 11/8/12 2:16 PM, Josh Berkus wrote:
Also, logging only the long-running queries is less useful than people
on this list seem to think. When I'm doing real performance analysis, I
need to see *everything* which was run, not just the slow stuff. Often
the real problem is a query which used
On 22/11/12 12:15, Greg Smith wrote:
On 11/8/12 2:16 PM, Josh Berkus wrote:
Also, logging only the long-running queries is less useful than people
on this list seem to think. When I'm doing real performance analysis, I
need to see *everything* which was run, not just the slow stuff. Often
For the log volume, would it help if there was some unexpectedness
threshold? That is, if a statement exceeds the duration threshold, it
gets explained, But then it only gets logged if the actual duration
divided by the cost estimate exceeds some threshold.
Thing is, pg_stat_plans makes
What prevents you from doing so? The performance impact? The volume
of logs generated?
Yes and yes.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Nov 7, 2012 at 4:55 PM, Josh Berkus j...@agliodbs.com wrote:
What prevents you from doing so? The performance impact? The volume
of logs generated?
Yes and yes.
I've never noticed a performance impact, unless you are having it
analyze, or having it log every query. How do you
11 matches
Mail list logo
