Tomeh, Husam wrote:
>
> Nothing was running except the job. The server did not look stressed out
> looking at top and vmstat. We have seen slower query performance when
> performing load tests, so I run the re-index on all application indexes
> and then issue a full vacuum. I ran the same thing on
Title: Re: [PERFORM] COPY insert performance
Chris,
You can try the Bizgres distribution of postgres (based on version 8.0.3), the COPY support is 30% faster as reported by OSDL (without indexes). This is due to very slow parsing within the COPY command, which is sped up using micro-optimized
Husam,
On 7/25/05 4:31 PM, "John A Meinel" <[EMAIL PROTECTED]> wrote:
> Tomeh, Husam wrote:
>>
>> Nothing was running except the job. The server did not look stressed out
>> looking at top and vmstat. We have seen slower query performance when
>> performing load tests, so I run the re-index on
Vacuum full takes an exclusive lock on the tables it runs against, so if you
have anything else reading the table while you are trying to run it, the
vacuum full will wait, possibly forever until it can get the lock.
What does the system load look like while you are running this? What does
vmstat
I'd say, "don't do that". Unless you've deleted a lot of stuff and are
expecting the DB to shrink, a full vacuum shouldn't really be needed. On
a DB that big a full vacuum is just going to take a long time. If you
really are shrinking, consider structuring things so you can just drop a
table inste
Chris Isaacson wrote:
> I need COPY via libpqxx to insert millions of rows into two tables. One
> table has roughly have as many rows and requires half the storage. In
> production, the largest table will grow by ~30M rows/day. To test the
> COPY performance I split my transactions into 10,000 r
Nothing was running except the job. The server did not look stressed out
looking at top and vmstat. We have seen slower query performance when
performing load tests, so I run the re-index on all application indexes
and then issue a full vacuum. I ran the same thing on a staging server
and it took
Title: Message
I need COPY via
libpqxx to insert millions of rows into two tables. One table has roughly
have as many rows and requires half the storage. In production, the
largest table will grow by ~30M rows/day. To test the COPY performance I
split my transactions into 10,000 rows. I
I have an 8.02 postgresql database with about 180 GB in size, running on
2.6 RedHat kernel with 32 GB of RAM and 2 CPUs. I'm running the vacuum
full analyze command, and has been running for at least two consecutive
days with no other processes running (it's an offline loading server). I
tweaked
I just want to know , for immediate data mirroring , what is the best
way for PostgreSQL . PostgreSQL is offering many mirror tools , but
which one is the best ?. Is there any other way to accomplish the task ?
You want to take a look at Slony-I or Mammoth Replicator.
http://www.slony.info/
Try Slony: www.slony.info
Shashi Kanth Boddula wrote:
Hi,
I have one customer who is using PostgreSQL 7.4.8 on Linux . He has some
problems with database mirroring . The details are follows.
The customer is using Linux on which PostgreSQL 7.4.8 along with Jboss
3.2.3 is running . He has 2 ser
Shashi Kanth Boddula wrote:
The customer is using DBmirror tool to mirror the database records of
primary to secondary . The customer is complaining that there is one day
(24 hours) delay between primary and secondray for database
synchronization . They have dedicated line and bandwidth , but
Hi,
I have one customer who is using PostgreSQL 7.4.8 on Linux . He has some problems with database mirroring . The details are follows.
The customer is using Linux on which PostgreSQL 7.4.8 along with Jboss 3.2
Lately, I've been reading a lot about these new Coraid AoE RAID
devices ( http://www.coraid.com ). They tout it as being fast and
cheap and better than iSCSI due to the lack of TCP/IP over the wire.
Is it likely that a 15-drive RAID 10 Linux software RAID would
outperform a 4-drive 10k SC
14 matches
Mail list logo
