Прежде всего, ссылка вверху в самом вопросе уже сломана. Насколько я знаю, эта старая библиотека pgmex больше не поддерживается. Но есть совершенно новая высокопроизводительная клиентская библиотека PostgreSQL PgMex
написан на 100% на C и связан с последней версией PostgreSQL 9.6 libpq.
Как уже указывалось, вы можете использовать JDBC напрямую, но, по-моему, лучше по крайней мере использовать один из доступных способов ускорить выполнение запросов. Например, вы можете применить что-то подобное описанной в интересной статье «Ускорение SQL-запросов Matlab-JDBC», опубликованной на недокументированном веб-сайте Matlab. Основная причина снижения производительности драйвера JDBC PostgreSQL связана со значительными накладными расходами на преобразование данных в / из собственных форматов Matlab (объекты Java в Matlab и наоборот).
Но сам JDBC имеет определенные ограничения, которые нельзя обойти для существенно больших наборов данных. Это легко увидеть, например, если вам приходится иметь дело с массивами. Давайте посмотрим на следующую таблицу, сравнивающую производительность вставки данных метода datainsert из Matlab Database Toolbox (работающего с PostgreSQL именно через прямое соединение JDBC, так что его можно рассматривать как соответствующий представитель коннекторов на основе JDBC) с один из batchParamExec из упомянутого PgMex для случая массивов:
+-----------+-----------+--------------+------------------+
| Number of | Data size | Time for | Time for |
| tuples | | datainsert | batchParamExec |
| | | (sec.) | (sec.) |
+-----------+-----------+--------------+------------------+
| 20000 | 23Mb | 37.0255 | 1.1217 |
+-----------+-----------+--------------+------------------+
| 40000 | 46Mb | 72.4008 | 2.2669 |
+-----------+-----------+--------------+------------------+
| 60000 | 69Mb | 112.4428 | 3.2055 |
+-----------+-----------+--------------+------------------+
| 80000 | 92Mb | n/a | 4.2073 |
+-----------+-----------+--------------+------------------+
| 100000 | 115Mb | n/a | 5.5277 |
+-----------+-----------+--------------+------------------+
| 300000 | 346Mb | n/a | 14.3530 |
+-----------+-----------+--------------+------------------+
| 600000 | 691Mb | n/a | 28.3156 |
+-----------+-----------+--------------+------------------+
| 800000 | 922Mb | n/a | 38.2579 |
+-----------+-----------+--------------+------------------+
| 1000000 | 1152Mb | n/a | 47.8714 |
+-----------+-----------+--------------+------------------+
| 1200000 | 1382Mb | n/a | 56.6258 |
+-----------+-----------+--------------+------------------+
| 1400000 | 1613Mb | n/a | 65.9764 |
+-----------+-----------+--------------+------------------+
| 1750000 | 2016Mb | n/a | 82.1829 |
+-----------+-----------+--------------+------------------+
| 2000000 | 2304Mb | n/a | 93.5854 |
+-----------+-----------+--------------+------------------+
Здесь n/a соответствует объемам данных, которые вызывают проблему «нехватки памяти кучи Java» для данного метода вставки, размер кучи Java для всех этих экспериментов был равен 939 МБ. Результаты этих и других экспериментов, представленные в графической форме, а также подробности экспериментов см. В следующем
Статья "Сравнение производительности коннекторов PostgreSQL в Matlab" ).
Таким образом, если вам приходится иметь дело с данными, имеющими простые скалярные типы и не очень большой объем, JDBC может полностью удовлетворить вас. Но в остальном
ИМХО лучше использовать решения на основе libpq, такие как PgMex, упомянутые выше. Помимо PgMex, существует, например,
пакет с открытым исходным кодом mexPostgres (вы можете найти его на веб-сайте Matlab Central), написанный на C ++. Эта библиотека
анализирует данные на основе их текстового представления (с помощью функции PQgetvalue из libpq) и только для очень ограниченного списка типов данных
(на самом деле это скалярные числа и логики, времена, даты, временные метки и интервалы, а также строки, более сложные типы, такие как массивы, снова выходят за рамки). Но передача через текстовое представление очень медленная и может использоваться снова только для не очень больших наборов данных. Что касается PgMex, эта библиотека реализует очень эффективный канал передачи двоичных данных между Matlab и PostgreSQL без разбора текста. Кроме того, все сделано в Matlab-дружественных и родным способом (в виде матриц,
многомерные массивы, структуры и другие произвольные форматы Matlab).
Давайте дадим подсказку, как обращаться с последней библиотекой, основываясь на примере, взятом из одного из ответов выше, но переписанном с использованием PgMex. А именно, импорт данных осуществляется с помощью следующего кода (мы предполагаем, что в приведенном ниже коде значения всех параметров, отмеченных <>, заполнены правильно, а также что соответствующая таблица уже существует в базе данных):
% Create the database connection
dbConn=com.allied.pgmex.pgmexec('connect',[...
'host=<yourhost> dbname=<yourdb> port=<yourport> '...
'user=<your_postgres_username> password=<your_postgres_password>']);
% A test query
sql='select * from <table>'; % Gets all records
pgResult=com.allied.pgmex.pgmexec('exec',dbConn,sql); % Perform this test query
% Read the results
nFields=com.allied.pgmex.pgmexec('nFields',pgResult);
outCVec=cell(nFields,1);
fieldSpecStr='%<field_type_1> %<field_type_2> ...';
inpCVec=num2cell(0:nFields-1);
[outCVec{:}]=com.allied.pgmex.pgmexec('getf',pgResult,...
fieldSpecStr,inpCVec{:});
Пожалуйста, смотрите документацию "getf" на веб-сайте PgMex для деталей относительно формата ввода.
и выходные аргументы (включая fieldSpecStr). Каждый элемент outCVec
содержит структуру, имеющую поля valueVec, isNullVec и isValueNullVec. Все эти поля имеют размер
по первому измерению, совпадающему с числом извлеченных кортежей, valueVec содержит значения
соответствующее поле таблицы, тогда как isNullVec и isValueNullVec являются индикаторами NULL.