Re: [PERFORM] Database size growing over time and leads to performance impact

2010-04-01 Thread Scott Carey
On Mar 31, 2010, at 1:47 PM, Robert Haas wrote: On Wed, Mar 31, 2010 at 4:37 PM, Scott Carey sc...@richrelevance.com wrote: On Mar 27, 2010, at 6:35 AM, Andy Colson wrote: Dont VACUUM FULL, its not helping you, and is being removed in newer versions. Off topic: How is that going to

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-04-01 Thread Tom Lane
Scott Carey sc...@richrelevance.com writes: Still off topic: Will CLUSTER/VF respect FILLFACTOR in 9.0? As far as I can tell in 8.4, it does not. Works for me, in both branches. regards, tom lane -- Sent via pgsql-performance mailing list

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-04-01 Thread Scott Carey
On Apr 1, 2010, at 1:42 PM, Tom Lane wrote: Scott Carey sc...@richrelevance.com writes: Still off topic: Will CLUSTER/VF respect FILLFACTOR in 9.0? As far as I can tell in 8.4, it does not. Works for me, in both branches. I stand corrected. I must have done something wrong in my

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-03-31 Thread Scott Carey
On Mar 27, 2010, at 6:35 AM, Andy Colson wrote: Dont VACUUM FULL, its not helping you, and is being removed in newer versions. Off topic: How is that going to work? CLUSTER doesn't work on tables without an index. I would love to be able to CLUSTER on some column set that doesn't

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-03-31 Thread Robert Haas
On Wed, Mar 31, 2010 at 4:37 PM, Scott Carey sc...@richrelevance.com wrote: On Mar 27, 2010, at 6:35 AM, Andy Colson wrote: Dont VACUUM FULL, its not helping you, and is being removed in newer versions. Off topic:  How is that going to work?  CLUSTER doesn't work on tables without an

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-03-31 Thread Alvaro Herrera
Scott Carey wrote: On Mar 27, 2010, at 6:35 AM, Andy Colson wrote: Dont VACUUM FULL, its not helping you, and is being removed in newer versions. Off topic: How is that going to work? CLUSTER doesn't work on tables without an index. I would love to be able to CLUSTER on some

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-03-30 Thread Gnanakumar
; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Database size growing over time and leads to performance impact On 03/27/2010 08:00 AM, Gnanakumar wrote: Hi, We're using PostgreSQL 8.2. Recently, in our production database, there was a severe performance impact.. Even though, we're

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-03-30 Thread Andy Colson
On 3/30/2010 6:17 AM, Gnanakumar wrote: We're using pgpool-II version 2.0.1 for PostgreSQL connection management. pgpool configurations are: num_init_children = 450 child_life_time = 300 connection_life_time = 120 child_max_connections = 30 As you recommended, I ran ps -ax|grep postgres at

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-03-28 Thread Greg Smith
Pierre C wrote: If you realize you got a bloat problem, for instance due to a misconfigured vacuum, use CLUSTER, which re-generates table AND index data, and besides, having your table clustered on an index of your choice can boost performance quite a lot in some circumstances. 8.2 is so old

[PERFORM] Database size growing over time and leads to performance impact

2010-03-27 Thread Gnanakumar
Hi, We're using PostgreSQL 8.2. Recently, in our production database, there was a severe performance impact.. Even though, we're regularly doing both: 1. VACUUM FULL ANALYZE once in a week during low-usage time and 2. ANALYZE everyday at low-usage time Also, we noticed that the

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-03-27 Thread Andy Colson
On 03/27/2010 08:00 AM, Gnanakumar wrote: Hi, We're using PostgreSQL 8.2. Recently, in our production database, there was a severe performance impact.. Even though, we're regularly doing both: 1. VACUUM FULL ANALYZE once in a week during low-usage time and 2. ANALYZE everyday at low-usage

Re: [PERFORM] Database size growing over time and leads to performance impact

2010-03-27 Thread Pierre C
1. VACUUM FULL ANALYZE once in a week during low-usage time and VACUUM FULL compacts tables, but tends to bloat indexes. Running it weekly is NOT RECOMMENDED. A correctly configured autovacuum (or manual vacuum in some circumstances) should maintain your DB healthy and you shouldn't