> 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
-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
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
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
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
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
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
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
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
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
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
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
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
>>> 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
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
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
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
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
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
19 matches
Mail list logo
