day 2 results - Mailing list pgsql-hackers

From Paul A Vixie
Subject day 2 results
Date
Msg-id 200012201653.IAA37798@redpaul.mfnx.net
Whole thread Raw
Responses Re: day 2 results
List 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!


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug in CREATE OPERATOR
Next
From: Luis Magaña
Date:
Subject: Compiling on Win32