On Tue, 29 Apr 2008, John Rouillard wrote:
So swap the memory usage from the OS cache to the postgresql process.
Using 1/4 as a guideline it sounds like 600,000 (approx 4GB) is a
better setting. So I'll try 30 to start (1/8 of memory) and see
what it does to the other processes on the box.
On Mon, Apr 28, 2008 at 02:16:02PM -0400, Greg Smith wrote:
> On Mon, 28 Apr 2008, John Rouillard wrote:
>
> > 2008-04-21 11:36:43 UTC @(2761)i: LOG: checkpoints ... (27 seconds
> > apart)
> > so I changed:
> > checkpoint_segments = 30
> > checkpoint_warning = 150
>
> That's good, but you
On Tue, Apr 29, 2008 at 05:19:59AM +0930, Shane Ambler wrote:
> John Rouillard wrote:
>
> >We can't do this as we are backfilling a couple of months of data
> >into tables with existing data.
>
> Is this a one off data loading of historic data or an ongoing thing?
Yes it's a one off bulk data l
John Rouillard wrote:
We can't do this as we are backfilling a couple of months of data
into tables with existing data.
Is this a one off data loading of historic data or an ongoing thing?
The only indexes we have to drop are the ones on the primary keys
(there is one non-primary key index
On Mon, 28 Apr 2008, John Rouillard wrote:
2008-04-21 11:36:43 UTC @(2761)i: LOG: checkpoints ... (27 seconds apart)
so I changed:
checkpoint_segments = 30
checkpoint_warning = 150
That's good, but you might go higher than 30 for a bulk loading operation
like this, particularly on 8.1
On Mon, Apr 28, 2008 at 06:53:09PM +0100, Heikki Linnakangas wrote:
> John Rouillard wrote:
> >We are running postgresql-8.1.3 under Centos 4
> You should upgrade, at least to the latest minor release of the 8.1
> series (8.1.11), as there has been a bunch of important bug and security
> fixes. O
John Rouillard wrote:
We are running postgresql-8.1.3 under Centos 4
You should upgrade, at least to the latest minor release of the 8.1
series (8.1.11), as there has been a bunch of important bug and security
fixes. Or even better, upgrade to 8.3, which has reduced the storage
size of espec
Hi all:
We are loading in a number (100+) of sql files that are about 100M in
size. It takes about three hours to load the file. There is very
little load on the database other than the copy from operations.
We are running postgresql-8.1.3 under Centos 4 on a RAID 1/0 array
with 4 disks (so we h
