Re: Performance die when COPYing to table with bigint PK
От | Vitalii Tymchyshyn |
---|---|
Тема | Re: Performance die when COPYing to table with bigint PK |
Дата | |
Msg-id | 4E3AC4CE.2000507@gmail.com обсуждение исходный текст |
Ответ на | Re: Performance die when COPYing to table with bigint PK ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Performance die when COPYing to table with bigint PK
|
Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления: