Hello.
I've found strange behavior of my pg installation (tested both 8.4 and
9.0 - they behave same) on FreeBSD platform.
In short - when some table have PK on bigint field - COPY to that
table from file becomes slower and slower as table grows. When table
reaches ~5GB - COPY of 100k records may
Quite possible.
But anyway - I don't think performance degradation must be so huge in
case of using UNIQUE indexes.
On Mon, Aug 1, 2011 at 12:06 PM, Vitalii Tymchyshyn wrote:
> 31.07.11 16:51, Robert Ayrapetyan написав(ла):
>>
>> Hello.
>>
>> I've found s
ay be superfluous, but I have no resources to check on
different platforms with different filesystems).
On Mon, Aug 1, 2011 at 12:15 PM, Robert Ayrapetyan
wrote:
> Quite possible.
> But anyway - I don't think performance degradation must be so huge in
> case of using UNIQUE indexes
itical effect.
On Tue, Aug 2, 2011 at 8:41 PM, Kevin Grittner
wrote:
> Robert Ayrapetyan wrote:
>
>> So I'm still convinced - this bug relates to FreeBSD 64-bit + UFS
>> + bigint column index
>> (some of these may be superfluous, but I have no resources to
>>
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 wrote:
> 04.08.11 18:59, Kevin Grittner написав(ла):
>>
>> Robert Ayrapetyan wrote:
>>>
>>> Kevin G
Grittner
wrote:
> Robert Ayrapetyan wrote:
>
>> 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 o
gt; Четвер, 4 серпня 2011 р. користувач Robert Ayrapetyan
> написав:
>> 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 (
