Всем доброго!
Столкнулся с проблемой.
Перевел проект с MySQL на Postgres!
Есть проблема.
Мне надо из CSV файла перенести записи в таблицу.
Сделал по аналогии, как я делал в MySQL. Но понял что на добавление 220 тыс. записей (в CSV всего два столбца.) уходит очень много времени.
Почитал в интернете.
1) Делал все в одной транзакции... не помогло, ощутимого приростса я вообще не заметил.
BEGIN; INSERTs.... INSERTs.... INSERTs.... ... INSERTs.... COMMIT;
SET autocommit TO 'off'; строки с INSERT COMMIT; SET autocommit TO 'on';
По поводу последнего... я крутил крутил, ниче не получается у меня:(
1) я не хочу тупо делать экспорт из CSV, т.к. мне надо проверить данные на валидность, и в зависимости от проверки в табличку добавляю ~ след.:
номер продукта | цена | ID Excel | Допуск
как лучше сделать?
я делал что-то типа такого..
COPY "table1"(part_number,price,id_excel,"valid") FROM STDIN WITH DELIMITER AS ' '; '3333333' '666,43' 1 1 '33333334' '1111,43' 1 1 \.
ПС. Самое главное) пишу на PHP!
Ещё бы у вас pgAdmin
Ещё бы у вас pgAdmin работал.
Обратите внимание на слова "FROM STDIN" и попробуйте найти у pgAdmin этот самый stdin и stdout заодно.
За последние полгода прочно пришёл к убеждению, что pgAdmin - зло!
Люди начинают пользоваться графическими инструментами в глубоком убеждении, что по-другому никак нельзя.
Наиболее универсальный и лёгкий psql просто забыт! Об остальных утилитах командной строки большинство не имеют никакого представления вообще.
ну я им пользуюсь только
ну я им пользуюсь только потому, что это первое что мне попалось на глаза))) у самого сервера, сам все настроил, а вот с COPY не могу разобраться(
помогите плз..
220 000 инсертов работает ~4.30 минут... ну не должно же быть такое!
Так вроде бы уже помог.
Так вроде бы уже помог. Помоему очень толсто намекнул.
Могу ещё доку порекомендовать. Там это явно написано в секции Notes:
http://postgresql.ru.net/manual/sql-copy.html
про pgAdmin
>За последние полгода прочно пришёл к убеждению, что pgAdmin - зло!
>Люди начинают пользоваться графическими инструментами в глубоком убеждении, что по-другому никак нельзя.
То, что люди не понимают как использовать те или иные функции системы вовсе не означает, что графическая оболочка обеспечивающая более удобный доступ к этим функциям (субъекивно) - зло. Если так рассуждать то любая графическая оболочка (интерфейс) становится - злом. Скорее всего пользователь ленив и не учил матчасть. Пользую pgAdmin и считаю его достаточно удобным средством разработки со своими достоинствами и недостатками.
Возможно я не совсем точно
Возможно я не совсем точно выразился: pgAdmin зло для начинающих!
Т.е. начинать надо всё-таки с psql, а потом, когда уже придёт понимание что как и почём, тогда уже можно и pgAdmin юзать и любой другой графический инструмент.
А когда начинают нажимать в гуе на кнопки, не понимая тех действий, которые при этом происходят - это не дело.
Более того, у начинающих возникает иллюзия, что кроме как pgAdmin'ом по-другому ничего сделать нельзя.
Сталкивался с такой же
Сталкивался с такой же проблемой.
COPY хорошо работает, но исходные данные действит-но должны быть валидными.
В моем случае вообще не получалось вставлять напрямую данные ( ... VALUES 'a','b','c' ...),
а приходилось искать их подзапросами:
... VALUES (SELECT ... WHERE <условие с 'а'>, SELECT ... WHERE <условие с 'b'>, ...
Единственное, что можно порекомендовать для оптимизации INSERT'ов - скомпилить запрос:
PREPARE (int, varchar, ...) AS
INSERT INTO table_name VALUES($1, $2, ...) -- выражение любой сложности, с запросами
BEGIN [TRANSACTION]
EXECUTE stm_name(1, 'a, 'b',...);
...
COMMIT;
Быстрее этого варианта, наверно, ничего не придумать.
P.S. По поводу COPY: команда позволяет брать данные не только с клавы (STDIN), но и из файла - это будет работать даже в "злом" pgAdmine...
COPY как замена INSERT'у
1. Берем филе.
2. Загружаем во временную таблицу.
3. Проверяем валидность. (удаляя не валидные данные)
4. Переносим в основную.
Ес-но в одной транзакции.