day 2 results

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!

Responses

Browse pgsql-hackers by date

  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...