From: | Robert Ayrapetyan <robert(dot)ayrapetyan(at)comodo(dot)com> |
---|---|
To: | Vitalii Tymchyshyn <tivv00(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance die when COPYing to table with bigint PK |
Date: | 2011-08-02 08:26:42 |
Message-ID: | CAAboi9s9MCsmqYPR+KqtXstPUodiE5MzvEpk1-e+C0n6FwkkyQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Seems this assumption is not right. Just created simple index on
bigint column - situation with huge performance
degradation repeated. Dropping this index solved COPY issues on the fly.
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 check on
different platforms with different filesystems).
On Mon, Aug 1, 2011 at 12:15 PM, Robert Ayrapetyan
<robert(dot)ayrapetyan(at)comodo(dot)com> wrote:
> 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 <tivv00(at)gmail(dot)com> wrote:
>> 31.07.11 16:51, Robert Ayrapetyan написав(ла):
>>>
>>> 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 take up to 20 mins. I've
>>> experimented with all params in configs, moved indexes to separate hdd
>>> etc - nothing made any improvement. However, once I'm dropping 64 bit
>>> PK - COPY of 100k records passes in seconds. Interesting thing - same
>>> table has other indexes, including composite ones, but none of them
>>> include bigint fields, that's why I reached decision that bug
>>> connected with indexes on bigint fields only.
>>
>> I did see this behavior, but as for me it occurs for UNIQUE indexes only
>> (including PK), not dependent on field type.
>> You can check this by dropping PK and creating it as a regular non-unique
>> index.
>>
>> 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
>
--
Ayrapetyan Robert,
Comodo Anti-Malware Data Processing Analysis and Management System (CAMDPAMS)
http://repo-qa.camdpams.odessa.office.comodo.net/mediawiki/index.php
From | Date | Subject | |
---|---|---|---|
Next Message | Vitalii Tymchyshyn | 2011-08-02 08:42:42 | Re: Performance die when COPYing to table with bigint PK |
Previous Message | Szymon Guz | 2011-08-02 06:47:41 | Re: Which Join is better |