Re: BUG #6136: Perfomance dies when using PK on 64-bit field

Поиск
Список
Период
Сортировка
От Robert Ayrapetyan
Тема Re: BUG #6136: Perfomance dies when using PK on 64-bit field
Дата
Msg-id CAAboi9vrFh2QOAAvnYPrXDUJRxNVAy6AQtPMzujCFRfZh-RVRg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #6136: Perfomance dies when using PK on 64-bit field  (Andres Freund <andres@anarazel.de>)
Список pgsql-bugs
Hi.

My simple testcase is:

> Testcase may be as simple as:
>
> CREATE TABLESPACE tblsp_ix LOCATION '/some_dedicated_hdd'
>
> CREATE TABLE tp_req
> (
>    id bigint PRIMARY KEY USING INDEX TABLESPACE tblsp_ix,
>    arrived timestamp NOT NULL,
>    real_ip inet,
>    tp_id integer NOT NULL,
>    action_id smallint NOT NULL,
>    subject_id smallint NOT NULL
> );
> CREATE INDEX ix_tp_req ON trafd.tp_req
>    USING btree (arrived, tp_id, action_id, subject_id) TABLESPACE tblsp_ix;
>
> Then generate ~500 files every ~7-10Mb in size (every file contains
> 80k-100k rows)
> with specified columns.
>
> Copy them to table one by one in cycle:
> psql -d fake_db -c "COPY tp_req(id, arrived, real_ip, tp_id,
> action_id, subject_id) FROM '${f}'"
>
> Filesystem on tblsp_ix is ufs2.

To your question - I've tried to drop ix_tp_req alone leaving PK in
place - situation was same.
Only dropping PK helps.


On Mon, Aug 1, 2011 at 11:10 AM, Andres Freund <andres@anarazel.de> wrote:
> Hi,
>
> What happens if you drop other indices with a similar size before starting the
> copy? It might just be the additional io-load (causing more checkpoints, more
> random io, etc) is causing the problems.
>
> Could you share your config and hw info?
>
> Greetings,
>
> Andres
>

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bernd Helmle
Дата:
Сообщение: Re: Warm Standby startup process unconditionally hangs
Следующее
От: "Alex Dragojlovic"
Дата:
Сообщение: BUG #6138: Install failed