On Sat, May 1, 2010 at 1:11 PM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> I don't have a stake in the ground on what the right settings are, but
>> I think it's fair to say that if you vacuum OR analyze much less
>> frequently than what we recommend my default, it might break.
>>
>
> I think th
On Sat, May 1, 2010 at 1:17 PM, Scott Marlowe wrote:
> On Sat, May 1, 2010 at 1:08 PM, Robert Haas wrote:
>> On Sat, May 1, 2010 at 12:13 PM, Scott Marlowe
>> wrote:
>>> On Fri, Apr 30, 2010 at 4:50 PM, Josh Berkus wrote:
Which is the opposite of my experience; currently we have several
>
On Sat, May 1, 2010 at 1:08 PM, Robert Haas wrote:
> On Sat, May 1, 2010 at 12:13 PM, Scott Marlowe
> wrote:
>> On Fri, Apr 30, 2010 at 4:50 PM, Josh Berkus wrote:
>>> Which is the opposite of my experience; currently we have several
>>> clients who have issues which required more-frequent anal
On Sat, May 1, 2010 at 12:13 PM, Scott Marlowe wrote:
> On Fri, Apr 30, 2010 at 4:50 PM, Josh Berkus wrote:
>> Which is the opposite of my experience; currently we have several
>> clients who have issues which required more-frequent analyzes on
>> specific tables. Before 8.4, vacuuming more fre
Greg Smith writes:
> If anything, I'd expect people to want to increase how often it runs,
> for tables where much less than 20% dead is a problem. The most common
> situation I've seen where that's the case is when you have a hotspot of
> heavily updated rows in a large table, and this may ma
Robert Haas wrote:
I don't have a stake in the ground on what the right settings are, but
I think it's fair to say that if you vacuum OR analyze much less
frequently than what we recommend my default, it might break.
I think the default settings are essentially minimum recommended
frequenci
On Fri, Apr 30, 2010 at 4:50 PM, Josh Berkus wrote:
> Which is the opposite of my experience; currently we have several
> clients who have issues which required more-frequent analyzes on
> specific tables. Before 8.4, vacuuming more frequently, especially on
> large tables, was very costly; vacu
On Wed, Apr 28, 2010 at 8:20 AM, Thomas Kellerer wrote:
> Rick, 22.04.2010 22:42:
>>
>> So, in a large table, the scale_factor is the dominant term. In a
>> small table, the threshold is the dominant term. But both are taken into
>> account.
>>
>> The default values are set for small tables; it is
2010/5/1 Cédric Villemain :
> 2010/4/28 Robert Haas :
>> On Mon, Apr 26, 2010 at 5:33 AM, Cédric Villemain
>> wrote:
>>> In the first query, the planner doesn't use the information of the 2,3,4.
>>> It just does a : I'll bet I'll have 2 rows in t1 (I think it should
>>> say 3, but it doesn't)
>>>
On Fri, Apr 30, 2010 at 6:50 PM, Josh Berkus wrote:
> Which is the opposite of my experience; currently we have several
> clients who have issues which required more-frequent analyzes on
> specific tables.
That's all fine, but probably not too relevant to the original
complaint - the OP backed of
2010/4/28 Robert Haas :
> On Mon, Apr 26, 2010 at 5:33 AM, Cédric Villemain
> wrote:
>> In the first query, the planner doesn't use the information of the 2,3,4.
>> It just does a : I'll bet I'll have 2 rows in t1 (I think it should
>> say 3, but it doesn't)
>> So it divide the estimated number of
11 matches
Mail list logo
