day 2 results
От | Paul A Vixie |
---|---|
Тема | day 2 results |
Дата | |
Msg-id | 200012201653.IAA37798@redpaul.mfnx.net обсуждение исходный текст |
Ответы |
Re: day 2 results
|
Список | 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 по дате отправления: