NOT NULL,
firm_id int8 NOT NULL,
rubric_id int4 NOT NULL,
CONSTRAINT firmrubric_pkey PRIMARY KEY (id)
);
CREATE UNIQUE INDEX firmrubric_firm_id_rubric_id ON public.firmrubric USING btree (firm_id, rubric_id);
количество firm_id больше чем количество rurbic_id в несколько сотен раз. Данные активно пишутся через INSERT ON CONFLIC IGNORE, вопрос - порядок ключа имеет роль на скорость вставки записей?
скорость - несколько тысяч вставок в минуту.
Пытаюсь найти узкое место у себя, через минут 20 работы скорость резко снижается до нескольких сотен в минуту. Сейчас уменьшил количество избыточных данных, скорость упала, но не так кардинально...
Влияет, но в такой таблицэ ограничение, на котором оно сыграет — всё равно позволит десятка полтора в секунду — или 1000 в минуту. И это на hdd, при индэксах в разы большэ RAM. То есть когда количество записей перевалит примерно 100 миллионов на гигабайт доступной RAM. Так что у вас, думаю, что-то другое. Скорость маловата для такой таблицы дажэ на hdd. PS Исправил там "1000 в секунду" на "1000 в минуту", это опечатка была.
Угу, спасибо за инфу
Обсуждают сегодня