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: | Raw Message | Whole Thread | 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... |