Re: [PERFORM] High CPU usage after partitioning

2013-01-21 Thread Andrew Dunstan
On 01/21/2013 10:05 AM, rudi wrote: Hello, I'm running postgresl 9.0. After partitioning a big table, CPU usage raised from average 5-10% to average 70-80%. - the table contains about 20.000.000 rows - partitions are selected using a trigger, based on an indexed field, a date (IF date_taken

Re: [PERFORM] High CPU usage after partitioning

2013-01-21 Thread Kevin Grittner
Merlin Moncure wrote: >> I'm running postgresl 9.0. After partitioning a big table, CPU >> usage raised from average 5-10% to average 70-80%. > First thing that jumps to mind is you have some seq-scan heavy > plans that were not seq-scan before. Make sure that all indexes are defined for each pa

Re: [PERFORM] High CPU usage after partitioning

2013-01-21 Thread Merlin Moncure
On Mon, Jan 21, 2013 at 9:05 AM, rudi wrote: > Hello, > > I'm running postgresl 9.0. After partitioning a big table, CPU usage raised > from average 5-10% to average 70-80%. > > - the table contains about 20.000.000 rows > - partitions are selected using a trigger, based on an indexed field, a dat

Re: [PERFORM] Analyze and default_statistics_target

2013-01-21 Thread Albe Laurenz
AJ Weber wrote: > What is the unit-of-measure used for default_statistics_target? Number of entries in pg_stats.histogram_bounds orpg_stats.most_common_vals. Yours, Laurenz Albe -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: h

Re: [PERFORM] Analyze and default_statistics_target

2013-01-21 Thread Heikki Linnakangas
On 21.01.2013 17:29, AJ Weber wrote: I was under the impression that the default_statistics_target was a percentage of rows to analyze. Maybe this is not the case? Nope. I ran an analyze during a "quiet point" last night and for a few of my large tables, I didn't get what I consider a reasona

[PERFORM] Analyze and default_statistics_target

2013-01-21 Thread AJ Weber
I was under the impression that the default_statistics_target was a percentage of rows to analyze. Maybe this is not the case? I ran an analyze during a "quiet point" last night and for a few of my large tables, I didn't get what I consider a reasonable sampling of rows. When running with "v

[PERFORM] High CPU usage after partitioning

2013-01-21 Thread rudi
Hello, I'm running postgresl 9.0. After partitioning a big table, CPU usage raised from average 5-10% to average 70-80%. - the table contains about 20.000.000 rows - partitions are selected using a trigger, based on an indexed field, a date (IF date_taken >= x AND date_taken < y) - I created 5 pa