On 2/26/13 11:19 AM, Robert Haas wrote:
On Mon, Feb 25, 2013 at 10:22 PM, Greg Stark wrote:
On Mon, Feb 25, 2013 at 8:26 PM, Robert Haas wrote:
On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby wrote:
We actually do that in our application and have discovered that random
sampling can end up signif
On Mon, Feb 25, 2013 at 10:22 PM, Greg Stark wrote:
> On Mon, Feb 25, 2013 at 8:26 PM, Robert Haas wrote:
>> On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby wrote:
>>> We actually do that in our application and have discovered that random
>>> sampling can end up significantly skewing your data.
>>
>>
On Mon, Feb 25, 2013 at 8:26 PM, Robert Haas wrote:
> On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby 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?
Sampling is a pretty big area of s
On Sun, Feb 24, 2013 at 7:27 PM, Jim Nasby 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 Company
--
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 onl
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
the
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 to
> 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 mak
On Wed, Nov 7, 2012 at 4:55 PM, Josh Berkus 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 measure the imp
> 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:
http://www.postgre
11 matches
Mail list logo
