Нужно вставить в базу много значений(1-15мегабайт). Вопрос, как лучше(быстрее, оптимальнее) реализовать.

1) Циклом закилываем в базу по одному INSERT`ы
2) Циклом склеиваем большую строку INSERT`ов и одним запросом кидаем в базу
3) Одним запросом вида INSERT INTO table (row1...rowN) VALUES(row1...rowN),(row1...rowN)...

Благодарю заранее за потраченое время)

http://en.wikipedia.org/wiki/Bulk_insert

Задавайте ясные и четкие вопросы

Добавлено через 1 минуту и 23 секунды
у каждого из описанных Вами способов есть свои преимущества и свои ограничения

Добавлено через 1 минуту и 46 секунд
причем как приемущества, так и ограничения - весьма платформозависимы

База данных PostgreSQL ОС Linux. Нужно синхронизировать бд между сервером и клиентом. =) Выбираю способ для этого. На самом деле интересно лишь, допустимо ли в данном случае пустить циклом INSERT`ы, или будут большие потери по сравнению с одним запросом?) Если чего то ещё не уточнил, то жду замечаний)

Увы, не являюсь экспертом по PG.
По тому только мои размышления.

Каких издержек вы стремитесь избежать? Я исхожу из того, что вы стремитесь избежать издержек на разборе запросов

Первый приведенный Вами способ позволяет использовать связанные переменные и подготовленные инструкции (prepared statements). Т.е. запрос парсится единожды и затем многократно выполняется для различных значений переменных. Думаю, постгр тут не является исключением и он поддерживает схожий функционал. Некоторые системы, например oracle, умеют и вовсе принимать в качестве связанных переменных массивы значений. Изучите, есть ли такая возможность в постгре. Мне кажется из приведенных Вами способов, первый - самый предпочтительный.

Эта фраза наводит на мысль, что мы имеем две БД и соответственно два сервера БД - локальный и удалённый... 
Это так или нет?

Zloxa, благодарю =) Буду пробовать.

Именно)

Именно, пардон, что? именно да или именно нет?

 Сорри) Я подразумевал согласие. Да) 2 БД. На одна на локальном и одна на удалённом серверах)

В таком случае я не понимаю, почему надо ставить в кривую позу клиента, когда у постгре есть такая фигня как репликация?
Клиенту достаточно только проинструктировать серверы, с кем и что синхронизировать, с какими учётными данными, что делать при коллизиях и пр., и дальше пусть серверы сами договариваются. Не надо делать работу сервера БД в клиентской части.

Удалённый сервер пока работает на MySQL и эта синхронизация есть временная мера)

В таком случае не будет ли более разумно выгрузить данные в файл, передать его на удалённый сервер и там загрузить?

Сейчас что то подобное и реализуется) Данные в виде сериализованного массива ПХП пишутся в файл и на другом сервере парсятся и льются в бд. или есть более верный вариант?.. Дело в том что у баз разная структура, опять же пока, и до тех пор пока всё не будет под управлением одной бд приходится ставить костыли.

А почему нельзя сразу выгрузить в файл, пригодный для загрузки через LOAD DATA INFILE? ведь тебе же по барабану, в какой форме выгружать на ПХП? и поройся в справке по постгре - может, там и выгрузка в файл подходящей структуры средствами СУБД найдётся...

Akina, насчёт выгрузки средствами СУБД я думал, но так как таблы имеют разную структуру это проблематично, а вот кормить базу файлами через LOAD DATA INFILE можно попробовать =) благодарю за советы.