Yes, you are right. Performance become even more awful. Can some techniques from pg_bulkload be implemented in postgres core? Current performance is not suitable for any enterprise-wide production system. 2011/8/5 Віталій Тимчишин <tivv00@xxxxxxxxx>: > > In my tests it greatly depends on if index writes are random or sequential. > My test time goes down from few hours to seconds if I add to the end of > index. > As for me, best comparision would be to make two equal int4 columns with > same data as in int8, two indexes, then perform the test. My bet it will be > slower than int8. > > Четвер, 4 серпня 2011 р. користувач Robert Ayrapetyan > <robert.ayrapetyan@xxxxxxxxxx> написав: >> All you are saying disproves following: >> >> in experiment I replaces bigint index: >> >> CREATE INDEX ix_t_big ON test.t USING btree (id_big) TABLESPACE tblsp_ix; >> >> with 4 (!) other indexes: >> >>>> If you look at the rest of my mail - you would notice 50 times >>>> difference in performance. >>>> What you would say? >>> >>> That accessing a page from RAM is more than 50 times as fast as a >>> random access of that page from disk. >>> >>> -Kevin >>> >> >> >> >> -- >> Ayrapetyan Robert, >> Comodo Anti-Malware Data Processing Analysis and Management System >> (CAMDPAMS) >> http://repo-qa.camdpams.odessa.office.comodo.net/mediawiki/index.php >> > > -- > Best regards, > Vitalii Tymchyshyn > -- Ayrapetyan Robert, Comodo Anti-Malware Data Processing Analysis and Management System (CAMDPAMS) http://repo-qa.camdpams.odessa.office.comodo.net/mediawiki/index.php -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
