Re: [PERFORM] Shared memory usage

2007-08-27 Thread Adam Tauno Williams
> I have a postgres 8.0 and ~400mb database with lots of simple selects > using indexes. > I've installed pgpool on the system. I've set num_init_children to 5 and > here is the top output. > One of postmasters is my demon running some insert/update tasks. I see > that they all use cpu heavil

[PERFORM] Postgres performance problem

2007-08-27 Thread Ruben Rubio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Note: I have already vacumm full. It does not solve the problem. I have a postgres 8.1 database. In the last days I have half traffic than 4 weeks ago, and resources usage is twice. The resource monitor graphs also shows hight peaks (usually th

Re: [PERFORM] Shared memory usage

2007-08-27 Thread Max Zorloff
On Mon, 27 Aug 2007 14:21:43 +0400, Adam Tauno Williams <[EMAIL PROTECTED]> wrote: I have a postgres 8.0 and ~400mb database with lots of simple selects using indexes. I've installed pgpool on the system. I've set num_init_children to 5 and here is the top output. One of postmasters is my demo

Re: [PERFORM] Postgres performance problem

2007-08-27 Thread Chris Mair
Hi, Note: I have already vacumm full. It does not solve the problem. I have a postgres 8.1 database. In the last days I have half traffic than 4 weeks ago, and resources usage is twice. The resource monitor graphs also shows hight peaks (usually there is not peaks) The performarce is getting po

Re: [PERFORM] Postgres performance problem

2007-08-27 Thread ruben
SO: CentOS release 4.3 (Final) (kernel: 2.6.9-34.0.1.ELsmp) Postgres: 8.1.3 I had some problems before with autovacuum. So, Each day I crontab execute: vacuumdb -f -v --analyze reindex database vacadb I saw logs (the output of vacuum and reindex) and there is no errors. If u need more info, I

Re: [PERFORM] partitioned table and ORDER BY indexed_field DESC LIMIT 1

2007-08-27 Thread Tomas Tamosaitis
Pn, 2007 08 24 14:53 +0600, Anton rašė: > Hi. > > I just created partitioned table, n_traf, sliced by month > (n_traf_y2007m01, n_traf_y2007m02... and so on, see below). They are > indexed by 'date_time' column. > Then I populate it (last value have date 2007-08-...) and do VACUUM > ANALYZE ON n_t

Re: [PERFORM] Postgres performance problem

2007-08-27 Thread Bill Moran
In response to Chris Mair <[EMAIL PROTECTED]>: > > Hi, > > > > Note: I have already vacumm full. It does not solve the problem. To jump in here in Chris' defense, regular vacuum is not at all the same as vacuum full. Periodic vacuum is _much_ preferable to an occasional vacuum full. The output

[PERFORM] Performance issue

2007-08-27 Thread Willo van der Merwe
Hi Guys, I have something odd. I have Gallery2 running on PostgreSQL 8.1, and recently I upgraded to 8.1.9-1.el4s1.1 (64bit). The issue here really is how do I get PostgreSQL to work with their horrible code. The queries they generate look something like : SELECT blah, blah FROM table1, table2 WH

Re: [PERFORM] Performance issue

2007-08-27 Thread Bill Moran
In response to Willo van der Merwe <[EMAIL PROTECTED]>: > Hi Guys, > > I have something odd. I have Gallery2 running on PostgreSQL 8.1, and > recently I upgraded to 8.1.9-1.el4s1.1 (64bit). The issue here really is > how do I get PostgreSQL to work with their horrible code. The queries > they gen

Re: [PERFORM] Performance issue

2007-08-27 Thread Tom Lane
Willo van der Merwe <[EMAIL PROTECTED]> writes: > I have something odd. I have Gallery2 running on PostgreSQL 8.1, and > recently I upgraded to 8.1.9-1.el4s1.1 (64bit). The issue here really is > how do I get PostgreSQL to work with their horrible code. The queries > they generate look something li

Re: [PERFORM] asynchronous commit feature

2007-08-27 Thread Decibel!
On Thu, Aug 23, 2007 at 09:09:00AM -0400, Merlin Moncure wrote: > I'm testing the new asynch commit feature on various raid > configurations and my early findings is that it reduces the impact of > keeping wal and data on the same volume. I have 10 disks to play > with, and am finding that it's fa

Re: [PERFORM] significant vacuum issues - looking for suggestions

2007-08-27 Thread Decibel!
On Fri, Aug 24, 2007 at 04:41:44PM -0400, Bill Moran wrote: > In response to Kevin Kempter <[EMAIL PROTECTED]>: > > > Hi List; > > > > I've just started working with a client that has been running Postgres > > (with > > no DBA) for a few years. They're running version 8.1.4 on 4-way dell boxes

Re: [PERFORM] asynchronous commit feature

2007-08-27 Thread Merlin Moncure
On 8/27/07, Decibel! <[EMAIL PROTECTED]> wrote: > On Thu, Aug 23, 2007 at 09:09:00AM -0400, Merlin Moncure wrote: > > I'm testing the new asynch commit feature on various raid > > configurations and my early findings is that it reduces the impact of > > keeping wal and data on the same volume. I h

Re: [PERFORM] significant vacuum issues - looking for suggestions

2007-08-27 Thread Kevin Grittner
>>> Decibel! <[EMAIL PROTECTED]> 08/27/07 4:00 PM >>> > > > They're running version 8.1.4 > > As for your pg_dump idea... why not just do a CREATE TABLE AS SELECT * > FROM bloated_table? That would likely be much faster than messing around > with pg_dump. He wanted to upgrade to 8.2.4. CREATE

Re: [PERFORM] significant vacuum issues - looking for suggestions

2007-08-27 Thread Kevin Kempter
On Monday 27 August 2007 15:56:33 Kevin Grittner wrote: > >>> Decibel! <[EMAIL PROTECTED]> 08/27/07 4:00 PM >>> > >>> > > > > They're running version 8.1.4 > > > > As for your pg_dump idea... why not just do a CREATE TABLE AS SELECT * > > FROM bloated_table? That would likely be much faster than m

Re: [PERFORM] significant vacuum issues - looking for suggestions

2007-08-27 Thread Decibel!
On Mon, Aug 27, 2007 at 04:56:33PM -0500, Kevin Grittner wrote: > >>> Decibel! <[EMAIL PROTECTED]> 08/27/07 4:00 PM >>> > > > > They're running version 8.1.4 > > > > As for your pg_dump idea... why not just do a CREATE TABLE AS SELECT * > > FROM bloated_table? That would likely be much faster th

Re: [PERFORM] significant vacuum issues - looking for suggestions

2007-08-27 Thread Kevin Kempter
On Monday 27 August 2007 15:00:41 you wrote: > On Fri, Aug 24, 2007 at 04:41:44PM -0400, Bill Moran wrote: > > In response to Kevin Kempter <[EMAIL PROTECTED]>: > > > Hi List; > > > > > > I've just started working with a client that has been running Postgres > > > (with no DBA) for a few years. The

Re: [PERFORM] significant vacuum issues - looking for suggestions

2007-08-27 Thread Kevin Kempter
On Monday 27 August 2007 16:04:39 Decibel! wrote: > On Mon, Aug 27, 2007 at 04:56:33PM -0500, Kevin Grittner wrote: > > >>> Decibel! <[EMAIL PROTECTED]> 08/27/07 4:00 PM >>> > > >>> > > > > > They're running version 8.1.4 > > > > > > As for your pg_dump idea... why not just do a CREATE TABLE AS SE

[PERFORM] server performance issues - suggestions for tuning

2007-08-27 Thread Kevin Kempter
Hi List; I've just inherited multiple postgres database servers in multiple data centers across the US and Europe via a new contract I've just started. Each night during the nightly batch processing several of the servers (2 in particular) slow to a crawl - they are dedicated postgres database