Глючит сервер при выборке большой таблицы

[Romkapost]

Глючит сервер при выборке большой таблицы

Есть большая таблица , около 9,6 млн записей,в скрипте делается выборка всех данных,
как

SELECT  * FROM table;

затем данные пишутся в файл, при этом сжимаются Zlib на лету

while($row = pg_fetch_assoc($sth))
{

$ins = "INSERT INTO ".$tables[$i]." (".join(',', array_keys($row)).") VALUES(".join(',', array_values($row)).");\n";
write_fp_handle(&$fp, $ins);
}

проблема в том что при копировании таких больших таблиц, сервак глючит,ничего не пишет в файл, для 1 млн нормально, это занимает около 3 минут, что посоветуете?

PS вариант с pg_dump не подходит

 

[Sad Spirit]

Автор оригинала: Romkapost
PS вариант с pg_dump не подходит

Почему не подходит?

 

[Romkapost]

задача написать некий веб-интерфейс для копирования и восстановления данных, но сам postgresql может физически работать на другом серваке, это мы обсуждали в фирме

 

[Gorynych]

что посоветуете?

выполнять по частям

 

[Romkapost]

я тоже подумал по частям, с помощью LIMIT count OFFSET start выбирать порциями например по 100 00 записей

 

[Gorynych]

Romkapost

тема "номер два" - лично мне кажется, что придуманная схема в принципе неверна: вы пытаетесь с помошью скрипта повторить то что должен делать стандартный дампер ( http://www.postgresql.org/docs/8.1/interactive/backup.html ), запускаемый (например) чере шел-скрипт

-~{}~ 26.09.06 15:36:

но сам postgresql может физически работать на другом серваке

- прохлопал. Но все равно - как-то безрадостно выглядит интерпретируемым скриптом дергать удаленный сервер чтобы получить с него дамп многомиллионной базы данных.

и уж точно не стал бы сжимать на лету. Вообще, по-моему решение задачи неверно. Надо написать веб-интерфейс для копирования и восстановления данных. Но база довольно объемна. Т.е. получить / закачать дамп "на лету" практически не реально. Соответственно, делать дампы надо на машине, где установлен PostgreSQL, штатными средствами, а забирать последнюю или нужную актаульную версию (если Вам нужно их именно оттуда забирать на другую машину) - уже можно через веб-интерфейс.

 

[Sad Spirit]

Автор оригинала: Romkapost
задача написать некий веб-интерфейс для копирования и восстановления данных, но сам postgresql может физически работать на другом серваке, это мы обсуждали в фирме

И чё? pg_dump замечательно работает с "другим серваком", укажи только параметр -h

 

[Romkapost]

Автор оригинала: Gorynych
Romkapost

тема "номер два" - лично мне кажется, что придуманная схема в принципе неверна: вы пытаетесь с помошью скрипта повторить то что должен делать стандартный дампер ( http://www.postgresql.org/docs/8.1/interactive/backup.html ), запускаемый (например) чере шел-скрипт

-~{}~ 26.09.06 15:36:

- прохлопал. Но все равно - как-то безрадостно выглядит интерпретируемым скриптом дергать удаленный сервер чтобы получить с него дамп многомиллионной базы данных.

и уж точно не стал бы сжимать на лету. Вообще, по-моему решение задачи неверно. Надо написать веб-интерфейс для копирования и восстановления данных. Но база довольно объемна. Т.е. получить / закачать дамп "на лету" практически не реально. Соответственно, делать дампы надо на машине, где установлен PostgreSQL, штатными средствами, а забирать последнюю или нужную актаульную версию (если Вам нужно их именно оттуда забирать на другую машину) - уже можно через веб-интерфейс.

я тоже думаю что изврат, но дело в том что сначала я и сделал через pg_dump, то что база большая - это да, но я сделаю разбивку по времени и кол-ва рядов, так как нужно предусмотреть контрольные точки, и в случае каких то проблем с коннектом была возможность продолжить с того момента, где прошёл обрыв связи

-~{}~ 28.09.06 23:15:

Автор оригинала: Sad Spirit
И чё? pg_dump замечательно работает с "другим серваком", укажи только параметр -h

как уже сказал начальство отклонило этот вариант, даже из за того что на сервере может быть отключена возможность запускать внешние программы через system() или exec()

 

[neko]

такая выборка буферизует все записи на клиенте.

используй курсор.