| From: | Paul A Vixie <vixie(at)mfnx(dot)net> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | day 2 results |
| Date: | 2000-12-20 16:53:09 |
| Message-ID: | 200012201653.IAA37798@redpaul.mfnx.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
the prior results (http://www.vix.com/~vixie/pgsql-results.png) showed:
~70ms usual INSERT time (~1.5sec -> ~1.25sec occasional)
~250ms usual SELECT time (~1.5sec occasional)
changing the attribute i key by to be PRIMARY KEY improved things a lot;
the new results (http://www.vix.com/~vixie/pgsql-indexed.png) show:
~80ms usual INSERT time (~1.28sec -> ~1.18sec occasional)
~100ms usual SELECT time (~1.18sec occasional)
VACUUM ANALYZE after the INSERTs made no performance difference at all,
which is good since no other modern database requires anything to be done
to improve performance after a large number of INSERTs. (i can understand
why COPY would need it, but not INSERT.)
the occasional 1.2sec has got to be due to some kind of scheduling or I/O
irregularity. i'm going to try it on a 500MB "MFS partition" next. it
turns out that MAPS RSS could actually live with "occasional 1.2sec" but
i want to make sure that its cause isn't trivial or my-stupidity-related.
just to let everybody know where i'm at with this. and-- THANKS for pgsql!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Naeslund(f) | 2000-12-20 16:58:27 | Re: PostgreSQL pre-7.1 Linux/Alpha Status... |
| Previous Message | Tom Lane | 2000-12-20 16:41:13 | Re: PostgreSQL pre-7.1 Linux/Alpha Status... |