day 2 results

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Bug in CREATE OPERATOR
Следующее
От: Luis Magaña
Дата:
Сообщение: Compiling on Win32