From: | "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | Pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Improving speed of copy |
Date: | 2002-09-20 16:18:30 |
Message-ID: | 3D8B97AE.23803.19DCC348@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20 Sep 2002 at 21:22, Shridhar Daithankar wrote:
> Mysql takes 221 sec. v/s 1121 sec. for postgres. For postgresql, that is around
> 11.5K rows per second. Each tuple has 23 fields with fixed length of around 100
> bytes
>
> I wrote a programs which does inserts in batches but none of thme reaches
> performance of copy. I tried 1K/5K/10K/100K rows in a transaction but it can
> not cross 2.5K rows/sec.
1121 sec. was time with postgres default of 64 buffers. With 30K buffers it has
degraded to 1393 sec.
One more issue is time taken for composite index creation. It's 4341 sec as
opposed to 436 sec for mysql. These are three non-unique character fields where
the combination itself is not unique as well. Will doing a R-Tree index would
be a better choice?
In select test where approx. 15 rows where reported with query on index field,
mysql took 14 sec. and psotgresql took 17.5 sec. Not bad but other issues
eclipse the result..
TIA once again..
Bye
Shridhar
--
revolutionary, adj.: Repackaged.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-09-20 16:19:04 | Re: Monitoring a Query |
Previous Message | Bruce Momjian | 2002-09-20 16:18:06 | Re: Monitoring a Query |