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
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
Josh Berkus escribió:
> #autovacuum_vacuum_scale_factor = 0.2
>
> This is set because in my experience, 20% bloat is about the level at
> which bloat starts affecting performance; thus, we want to vacuum at
> that level but not sooner. This does mean that very large tables which
> never have mor
> My guess is that the reason we run ANALYZE more frequently than vacuum
> (with the default settings) is that ANALYZE is pretty cheap. In many
> cases, if the statistical distribution of the data hasn't changed
> much, then it's not really necessary, but it doesn't cost much either.
> And for c
akp geek, 28.04.2010 16:37:
We have 8.4, which of AUTOVACUUM PARAMETERS can be set to handle individual
table?
All documented here:
http://www.postgresql.org/docs/current/static/sql-createtable.html
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make change
Check out the manual:
http://www.postgresql.org/docs/8.4/static/routine-vacuuming.html#AUTOVACUUM
Cheers,
Ken
On Wed, Apr 28, 2010 at 10:37:35AM -0400, akp geek wrote:
> Hi -
>don't want to side track the discussion. We have 8.4, which of
> AUTOVACUUM PARAMETERS can be set to handle
Hi -
don't want to side track the discussion. We have 8.4, which of
AUTOVACUUM PARAMETERS can be set to handle individual table? I ran into
bloat with small table only. Now the issue is being resolved.
Regards
On Wed, Apr 28, 2010 at 10:20 AM, Thomas Kellerer wrote:
> Rick, 22.04.2010
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 not being run for
large tables.
With 8.4 you can adjust the autovacuum
Robert Haas wrote:
> Rick wrote:
>> Since vacuum just recovers space, that doesn't seem to be nearly
>> as critical for performance?
>
> That doesn't really match my experience. Without regular
> vacuuming, tables and indices end up being larger than they ought
> to be and contain large amount
On Thu, Apr 22, 2010 at 4:42 PM, Rick wrote:
> On Apr 22, 2:55 pm, robertmh...@gmail.com (Robert Haas) wrote:
>> On Wed, Apr 21, 2010 at 11:06 AM, Rick wrote:
>> > I have a DB with small and large tables that can go up to 15G.
>> > For performance benefits, it appears that analyze has much less c
Rick wrote:
> 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.
Correct.
> The default values are set for small tables; it is not being run for
> large tables.
So decrease the scale factor an
On Apr 22, 2:55 pm, robertmh...@gmail.com (Robert Haas) wrote:
> On Wed, Apr 21, 2010 at 11:06 AM, Rick wrote:
> > I have a DB with small and large tables that can go up to 15G.
> > For performance benefits, it appears that analyze has much less cost
> > than vacuum, but the same benefits?
>
> Err
On Wed, Apr 21, 2010 at 11:06 AM, Rick wrote:
> I have a DB with small and large tables that can go up to 15G.
> For performance benefits, it appears that analyze has much less cost
> than vacuum, but the same benefits?
Err, no. ANALYZE gathers statistics for the query planner; VACUUM
clears out
I have a DB with small and large tables that can go up to 15G.
For performance benefits, it appears that analyze has much less cost
than vacuum, but the same benefits?
I can’t find any clear recommendations for frequencies and am
considering these parameters:
Autovacuum_vacuum_threshold = 5
Au
21 matches
Mail list logo
