Re: Performance die when COPYing to table with bigint PK - Mailing list pgsql-performance

From Віталій Тимчишин
Subject Re: Performance die when COPYing to table with bigint PK
Date
Msg-id CABWW-d1rdRspTaZXW_MLDZtRbreUxTcKJavOqpd6M0Lm34s5Sw@mail.gmail.com
Whole thread Raw
In response to Re: Performance die when COPYing to table with bigint PK  (Robert Ayrapetyan <robert.ayrapetyan@comodo.com>)
Responses Re: Performance die when COPYing to table with bigint PK
List pgsql-performance

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@comodo.com> написав:
> 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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Suspected Postgres Datacorruption
Next
From: Jeff Janes
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database