Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Оптимизация вставок. / 10 сообщений из 10, страница 1 из 1
12.02.2006, 23:37
    #33539771
robot648
robot648
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
Здравствуйте. В постгресе 7.4 проблема - слишком медленные вставки.

Вот таблица:
Код: plaintext
1.
2.
3.
4.
5.
6.
CREATE TABLE path (
    id bigserial,
    path varchar( 1024 ),
    PRIMARY KEY(id),
    UNIQUE(path)

);

Триггер к ней:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE OR REPLACE  FUNCTION path_trigger_func() RETURNS trigger AS '
DECLARE
BEGIN
if exists(select * from path where path=NEW.path) then
    return NULL;
end if;

return NEW;
END;
' LANGUAGE plpgsql;


CREATE TRIGGER path_t1 BEFORE INSERT ON path FOR EACH ROW
EXECUTE PROCEDURE  path_trigger_func();

Смысл триггера - реализовать аналог mysql'евского INSERT INGNORE INTO...
Вставки идут очень медленно - постгрес упиратся в диск по кол-ву транзакций. Думаю как раз изза этого триггера. Транзакции использую, т.е. большое число вставок делаю в одной транзакции. Есть ли у кого опыт, как это можно оптимизировать, чтобы вставки шли быстрее? COPY пробовал. Результат тоже не очень. Подумываю о переезде обратно на mysql :(
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
12.02.2006, 23:59
    #33539778
vfabr
vfabr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
ага переезжай обратно на майскл
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2006, 11:30
    #33540291
4321
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
1/ индекс на path.path
2/ Вставка конструкциями ~
INSERT INTO path (.,.,.,.)
SELECT ,,,
FROM any_t LEFT JOIN path p1
USING (path) WHERE p1.path IS NULL;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2006, 14:29
    #33540967
Кувалдин Роман
Кувалдин Роман
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
robot648...Смысл триггера - реализовать аналог mysql'евского INSERT INGNORE INTO...
Вставки идут очень медленно - постгрес упиратся в диск по кол-ву транзакций. Думаю как раз изза этого триггера. Транзакции использую, т.е. большое число вставок делаю в одной транзакции. Есть ли у кого опыт, как это можно оптимизировать, чтобы вставки шли быстрее? COPY пробовал. Результат тоже не очень. Подумываю о переезде обратно на mysql :(

Естественно. У тебя при каждой вставке идет проверка по всей таблице. НА КАЖДУЮ СТРОКУ.

Как вариант - попробуй сделать триггер FOR EACH STATEMENT.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2006, 16:45
    #33541450
robot648
robot648
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
43211/ индекс на path.path
2/ Вставка конструкциями ~
INSERT INTO path (.,.,.,.)
SELECT ,,,
FROM any_t LEFT JOIN path p1
USING (path) WHERE p1.path IS NULL;

Благодарю, попробую, орезультатах отпишу.

автор
Естественно. У тебя при каждой вставке идет проверка по всей таблице. НА КАЖДУЮ СТРОКУ.

Как вариант - попробуй сделать триггер FOR EACH STATEMENT.
А смысл? мне надо проверять наличие в таблицы именно каждой строки, которую я собираюсь вставить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2006, 17:05
    #33541531
vfabr
vfabr
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
может уник поставить?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2006, 19:26
    #33541895
Sad Spirit
Sad Spirit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
robot648
Смысл триггера - реализовать аналог mysql'евского INSERT INGNORE INTO...
Вставки идут очень медленно - постгрес упиратся в диск по кол-ву транзакций. Думаю как раз изза этого триггера. Транзакции использую, т.е. большое число вставок делаю в одной транзакции. Есть ли у кого опыт, как это можно оптимизировать, чтобы вставки шли быстрее? COPY пробовал. Результат тоже не очень. Подумываю о переезде обратно на mysql :(

Ну варианта тут 2:
1) обратно на mysql,
2) вставлять записи во временную таблицу, потом
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
insert into path
select * from path_temp
where not exists (
   select  1 
   from path
   where path.path = path_temp.path
);
естественно по скорости тоже будет не фонтан, т.к. varchar(1024)

а вообще, если требуется INSERT IGNORE, как и любое другое мысклёвое средство проё#а данных, значит чё-то не так с приложением.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2006, 19:45
    #33541934
Hordi
Hordi
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
ИМХО никакие решения, когда работу ввыполняет постгрес, тут не помогут. Я бы объявил блокирующую транзакцию, перегнал бы эту таблицу в память и при вставке локально выполнял бы все эти проверки.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
28.09.2007, 11:54
    #34834030
PythonWin
PythonWin
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
HordiИМХО никакие решения, когда работу ввыполняет постгрес, тут не помогут. Я бы объявил блокирующую транзакцию, перегнал бы эту таблицу в память и при вставке локально выполнял бы все эти проверки.
а если много записей (от 10 000) и каждая запись от 3Мб?
боюсь что просто не хватит ОЗУ :(
или можно как по частям ложить в память?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.09.2007, 12:48
    #34834301
ilejn
ilejn
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация вставок.
В дополнение.

1. Если коллизии встречаются достаточно редко, то можно просто в прикладном коде обрабатывать ошибку и игнорировать ее.
2. Если коллизии встречаются достаточно редко, можно попробовать изменить логику приложения таким образом, чтобы записи позволяли вставлять всегда, но реально использовали ту, у которой минимальный ID. Ну и какой-нибудь ночной чистильщик дублей.
3. Поскольку сортировка по path, видимо, не требуется, можно посмотреть на индекс на основе хэшей - должно быть побыстрее. Что на самом деле означает UNIQUE?

В исходном письме настораживает фраза "Думаю как раз изза этого триггера". Имело бы смысл это проверить и точно выяснить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Оптимизация вставок. / 10 сообщений из 10, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]