Re: Performance die when COPYing to table with bigint PK
От | Robert Ayrapetyan |
---|---|
Тема | Re: Performance die when COPYing to table with bigint PK |
Дата | |
Msg-id | CAAboi9syy0rRkhc0wy081-2K6mMbMJT9CQZTi9RRLBp540hrNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance die when COPYing to table with bigint PK (Vitalii Tymchyshyn <tivv00@gmail.com>) |
Список | pgsql-performance |
If you look at the rest of my mail - you would notice 50 times difference in performance. What you would say? On Thu, Aug 4, 2011 at 7:11 PM, Vitalii Tymchyshyn <tivv00@gmail.com> wrote: > 04.08.11 18:59, Kevin Grittner написав(ла): >> >> Robert Ayrapetyan<robert.ayrapetyan@comodo.com> wrote: >>> >>> Kevin Grittner<Kevin.Grittner@wicourts.gov> wrote: >> >>> [regarding tests which do show the problem] >>> tried same with 2 columns (bigint and int) - it didn't produced >>> such effect probably because data volume has critical effect. >> >> Based on what you're showing, this is almost certainly just a matter >> of pushing your volume of active data above the threshold of what >> your cache holds, forcing it to do disk access rather than RAM >> access for a significant portion of the reads. >> >> -Kevin > > Yep. Seems so. Plus famous "you'd better insert data, then create indexes". > On my database it takes twice the time for int8 then for int4 to insert > data. > Also it takes ~twice a time (2 hours) to add 200K of rows to 200M of rows > than to make an index over 200M of rows (1 hour). > > 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
В списке pgsql-performance по дате отправления: