powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Глюки и низкая произодительность ODBC драйвера
25 сообщений из 36, страница 1 из 2
Глюки и низкая произодительность ODBC драйвера
    #38728018
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сделал тестовую утилиту и выложил ее сюда - https://github.com/vvromanov/db_test
Результат профилирования лежит тут http://freepcrf.com/files/db_test_pq.pdf
Тестировалось на Centos 6.5 x64, ноутбук Lenovo t500, 8Gb, SSD. База расположено локально, 9.3
Что видно.
Очень низкая скорость. Простейший запрос выполнятеся 10 тысяч раз в секунду. Например, TimesTen делает это в 20 раз быстрее

Основная нагрузка приходиться на работу с сетью и совсем ненужный tz_convert

Есть странный глюк. Если при исполнеии prepared statement возникает ошибка, например, "duplicate key value violates unique constraint", то после этого стетмент портится. Последующие вызовы всегда приводят к ошибке. Приходится его разрушать, и создавать заново

Jabber: vromanov@gmail.com
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728191
Фотография Misha Tyurin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,

10К/sec - не так уж и плохо. покажите планы

tz_convert - а это база может и не делать, если уж "скорость" нам так нужна
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728203
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Misha Tyurin,

Какие такие планы? Выборка по первичному ключу в таблице из двух колонок! Вот сравнение этого теста с разными базами.

Код: plaintext
1.
2.
3.
4.
     Db Name | insert | select | update | delete |
  PostgreSql |   8034 |   9808 |   6857 |   9314 |
       MySql |  22675 |  16035 |  18782 |  19992 |
    TimesTen |  85792 | 198601 |  70466 |  66461 |
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728229
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,

Чего вы хотите получить в результате таких (“выборка по первичному ключу в таблице из двух колонок”) тестов? Показать, что для очень простых (примитивных даже) запросов PostgreSQL медленнее MySQL и ORACLE TimesTen? Это вполне ожидаемо.

Сравнивать с TimesTen совсем не корректно, т.к. это база в памяти, нету там IO.

Вы не могли бы выделить SQL скрипты для (1) инициализации и (2) прогонки теста — я бы тоже погонял у себя.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728237
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorov,

Я хочу показать, что ODBC драйвер Postgresql очень медленный и вносит существенную задержку в работу приложения. Где хранятся данные тут пофиг, можно вообще "select 1" выполнять.

Запросы вот
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE TABLE bench (
    id integer NOT NULL, 
    value integer NOT NULL, 
    CONSTRAINT bench_pk PRIMARY KEY (id) 
);

INSERT INTO bench (id, value) VALUES ($1, $2)
SELECT value FROM bench WHERE id=$1
UPDATE bench SET value=$1 WHERE id=$2
DELETE FROM bench WHERE id=$1

...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728269
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov Есть странный глюк. Если при исполнеии prepared statement возникает ошибка, например, "duplicate key value violates unique constraint", то после этого стетмент портится. Последующие вызовы всегда приводят к ошибке. Приходится его разрушать, и создавать заново

как портится ?
какая именно ошибка?


PS на одбс вы давно батон крошите, но как-то вяло.
может быть вам оно не надо ?
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728301
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovСделал тестовую утилиту и выложил ее сюда - https://github.com/vvromanov/db_test
Результат профилирования лежит тут http://freepcrf.com/files/db_test_pq.pdf
Тестировалось на Centos 6.5 x64, ноутбук Lenovo t500, 8Gb, SSD. База расположено локально, 9.3
Что видно.
Очень низкая скорость. Простейший запрос выполнятеся 10 тысяч раз в секунду. Например, TimesTen делает это в 20 раз быстрее

Основная нагрузка приходиться на работу с сетью и совсем ненужный tz_convert

Есть странный глюк. Если при исполнеии prepared statement возникает ошибка, например, "duplicate key value violates unique constraint", то после этого стетмент портится. Последующие вызовы всегда приводят к ошибке. Приходится его разрушать, и создавать заново

Jabber: vromanov@gmail.com


так уже обсуждалось что ODBC драйвер у PostgreSQL старый и небыстрый...
и опять же уже советовалось использовать напрямую libpq и сравнивать по скорости (не забывая использовать prepared запросы).

ODBC в общем устаревшее 100 лет назад решение... сейчас или Java+jdbc или Net+npgsql или нативные libpq для сишных клиентов.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728303
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovvyegorov,

Я хочу показать, что ODBC драйвер Postgresql очень медленный и вносит существенную задержку в работу приложения. Где хранятся данные тут пофиг, можно вообще "select 1" выполнять.



так известный факт и лечить его никто не будет ибо он никому кроме вас не нужен под highload где это становится актуально.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728312
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

Сценарий такой
Код: plaintext
1.
2.
3.
4.
db_insert(1,1);
db_insert(1,2);
db_insert(2,3);
db_select(2,&value);
первый запрос успешно выполнятеся.
второй возращает
Код: plaintext
1.
2.
3.
4.
5.
6.
Retcode [-1] when executing SQLExecute(stmt_insert)
Error [-1] in SQLExecute(stmt_insert)ERROR:
[unixODBC]ERROR: duplicate key value violates unique constraint "bench_pk"
Key (id)=(1) already exists.;
Error while executing the query
ODBC Error/Warning = 23505, Additional Error/Warning = 7
Третий возвращает
Код: plaintext
1.
2.
3.
4.
Retcode [-1] when executing SQLExecute(stmt_insert)
Error [-1] in SQLExecute(stmt_insert)ERROR:
[unixODBC]Error while executing the query
ODBC Error/Warning = S1000, Additional Error/Warning = 7
Четвертый успешно работает
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728317
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwqPS на одбс вы давно батон крошите, но как-то вяло.
может быть вам оно не надо ?
Оно нам надо по очень простой причине. Мы хотив нашем приложении поддержать работу с несколькими базами данных. Сейчас это TimesTen & PQ. ODBC именно для этого и предназначен - для стандартного интерфейса к разным базам данных.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728361
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Bogukтак уже обсуждалось что ODBC драйвер у PostgreSQL старый и небыстрый...
и опять же уже советовалось использовать напрямую libpq и сравнивать по скорости (не забывая использовать prepared запросы).
Приделаю еще к тесту libpq. Посмотрим что получится. В крайнем случае похоже придется писать свою реализацию подмножества ODBC.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728382
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovODBC Error/Warning = S1000, Additional Error/Warning = 7

про S1000 вы писали уйму времени тому . так и не выяснили ?

в http://www.postgresql.org/docs/current/static/errcodes-appendix.html этого кода нет. (в отличии от 23505 )

наверняка за это время вы таки выяснили, что это, и чем борется (я догадываюсь, но голословно предполагать не хочу).
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728400
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovqwwq,

Сценарий такой
Код: plaintext
1.
2.
3.
4.
db_insert(1,1);
db_insert(1,2);
db_insert(2,3);
db_select(2,&value);
первый запрос успешно выполнятеся.
второй возращает
Код: plaintext
1.
2.
3.
4.
5.
6.
Retcode [-1] when executing SQLExecute(stmt_insert)
Error [-1] in SQLExecute(stmt_insert)ERROR:
[unixODBC]ERROR: duplicate key value violates unique constraint "bench_pk"
Key (id)=(1) already exists.;
Error while executing the query
ODBC Error/Warning = 23505, Additional Error/Warning = 7
Третий возвращает
Код: plaintext
1.
2.
3.
4.
Retcode [-1] when executing SQLExecute(stmt_insert)
Error [-1] in SQLExecute(stmt_insert)ERROR:
[unixODBC]Error while executing the query
ODBC Error/Warning = S1000, Additional Error/Warning = 7
Четвертый успешно работает

Я сильно подозреваю что реальный error code от базы это 7...
а это значит что у вас происходит следующее

begin;
insert...;
--ошибка
и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете
rollback;

т.е. если внутри транзакции возникла ошибка то никакая комманда дальше в ней не пройдет пока вы ее не откатите.
И это не ошибка ODBC (хотя конечно диагностику она могла бы и более внятную давать).


--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728407
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk <>
а это значит что у вас происходит следующее

begin;
insert...;
--ошибка
и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете
rollback;
<>
вопрос, кто за begin отвечает.

есть подозрение -- что default/fetch (был такой ключ-модификатор в драйвере. как его отключить параметром строки подключения -- не помню).
но в случае error надо бы "end;" руками прослать -- оно и получшает
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728422
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Bogukbegin;
insert...;
--ошибка
и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете
rollback;
Я же не зря сделал в конце теста select. Он проходит без ошибки. Также по-умолчанию включен автокоммит.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728577
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanov,
Обновим табличку. Табличка показывает, что в случае PQ, ODBC не вносит существенной задержки (20-25%), куда существеннее использование TCP/IP вместо сокетов. Особенно полезна первая колонка (SELECT 1)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
             Db Name |select1 | insert | select | update | delete |
  PostgreSql (libpq) |  22990 |  15975 |  16416 |  10610 |  15529 | unix_socket
  PostgreSql (libpq) |  14877 |  11791 |  12405 |   9006 |  11950 | tcp/ip
   PostgreSql (ODBC) |  11888 |   9635 |   9026 |   7773 |   9625 | tcp/ip
        MySql (ODBC) |  24884 |  22349 |  15943 |  18581 |  19848 | unix_socket, Memory
        MySql (ODBC) |  24806 |  14148 |  13864 |  11473 |  12225 | unix_socket, InnoDB 
        MySql (ODBC) |  13934 |  16372 |  12617 |  14208 |  15150 | tcp/ip, Memory
        MySql (ODBC) |  13103 |  11727 |  11289 |   9972 |  10438 | tcp/ip, InnoDB
     TimesTen (ODBC) | 143061 |  82169 | 207125 |  73152 |  62719 | shm
     TimesTen (ODBC) |   7796 |  14282 |   7787 |  13910 |  12945 | tcp/ip
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728589
Жоао!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vromanov,
ваша табличка еще и вот что показывает:
Код: plaintext
1.
2.
3.
          Db Name |select1 | insert | select | update | delete |
PostgreSql (ODBC) |  11888 |   9635 |   9026 |   7773 |   9625 | tcp/ip
     MySql (ODBC) |  13103 |  11727 |  11289 |   9972 |  10438 | tcp/ip, InnoDB
  TimesTen (ODBC) |   7796 |  14282 |   7787 |  13910 |  12945 | tcp/ip
Сравнивать надо сравнимое, а не shared memory с tcp/ip.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728606
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovvromanov,
Обновим табличку. Табличка показывает, что в случае PQ, ODBC не вносит существенной задержки (20-25%), куда существеннее использование TCP/IP вместо сокетов. Особенно полезна первая колонка (SELECT 1)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
             Db Name |select1 | insert | select | update | delete |
  PostgreSql (libpq) |  22990 |  15975 |  16416 |  10610 |  15529 | unix_socket
  PostgreSql (libpq) |  14877 |  11791 |  12405 |   9006 |  11950 | tcp/ip
   PostgreSql (ODBC) |  11888 |   9635 |   9026 |   7773 |   9625 | tcp/ip
        MySql (ODBC) |  24884 |  22349 |  15943 |  18581 |  19848 | unix_socket, Memory
        MySql (ODBC) |  24806 |  14148 |  13864 |  11473 |  12225 | unix_socket, InnoDB 
        MySql (ODBC) |  13934 |  16372 |  12617 |  14208 |  15150 | tcp/ip, Memory
        MySql (ODBC) |  13103 |  11727 |  11289 |   9972 |  10438 | tcp/ip, InnoDB
     TimesTen (ODBC) | 143061 |  82169 | 207125 |  73152 |  62719 | shm
     TimesTen (ODBC) |   7796 |  14282 |   7787 |  13910 |  12945 | tcp/ip


основной и наиболее интересный вопрос в том что как мне кажется вы тестируете в 1 поток/коннект.
Результаты я должен признать у вас весьма интересные получились.
Но, как правило для базы вопрос в том сколько вообще запросов в секунду данный сервер может давать (в оптимальное количество потоков). PostgreSQL - 1 коннект - 1 процесс и никакой паралелизации обработки внутри (хотя что внутри SELECT 1 можно парралельно делать не очень понятно), так что производительность работы именно через 1 коннект обычно не очень критична.

Поскольку я кода вашего теста на libpq не вижу то могу предположить что вы могли не использовать prepared запросы и с ними даже в один коннект было бы заметно быстнее (
т.е. вместо PQexec или PQexecParams
использовать однократно PQprepare и далее для кажого вызова использовать в цикле измерения скорости PQexecPrepared
), eсли у вас так и сделано то скорее всего вы весьма близко подошли к пределу одного коннекта... если нет то попробуйте может будет повеселее (особенно за пределами select 1 запроса).

Наверное опять же для работы через Libpq в 1 коннект какую то дополнительную производительность вы сможете получить через http://www.postgresql.org/docs/9.4/static/libpq-async.html но это уже на мой перебор.

PS: интересно сколько ядер процессора timesten задействует через shm ? (всетаки 10 кратная разница это многовато).

PS: вам действительно критична производительность в 1 коннект?
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728644
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vromanovMaxim Bogukbegin;
insert...;
--ошибка
и теперь ЛЮБОЙ запрос который вы будете пробовать выполнять будет давать эту ошибку пока вы не сделаете
rollback;
Я же не зря сделал в конце теста select. Он проходит без ошибки. Также по-умолчанию включен автокоммит.пока -- зря
переставьте его (селект) местами с предыдущим (послеошибошным) инсертом -- тогда сможете что-то утверждать
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728675
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Жоао!shared memory с tcp/ip.
Отлично! Как мне сравнить работу ODBC с PostgreSql через SHM или хотябы через сокет? Я собственно про это и пишу, что нет возможности выбрать правильный и быстрый способ подключения
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728683
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
эттапока -- зря
переставьте его (селект) местами с предыдущим (послеошибошным) инсертом -- тогда сможете что-то утверждать

Переставил. Селект успешно выполняется и до и после insert, который падает. У нас просто уже это в продакшене и мы знаем, что после подобной ошибки надо разрушать стейтмент. Остальные работают.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728694
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim BogukПоскольку я кода вашего теста на libpq не вижу то могу предположить что вы могли не использовать prepared запросы и с ними даже в один коннект было бы заметно быстнее (
т.е. вместо PQexec или PQexecParams
Я же опубликовал в первом сообщении ссылку на код. На всякий случай вот так делается select 1 (см ниже). Timesten задействует ОДНО ядро. Там вообще вся работа с базой происходит внутри самого драйвера. Т.е. при прогоне теста 100% ядра будет жрать приложение, а сам сервер занимается всякой рутиной типа сброса логов на диск, репликации, итд. Проводя тесты в один поток я замеряю эффективность драйверов. Т.е. какие будут накладные работы при выполнениии любого запроса. Запросы у меня очень простые. Специально проверил сейчас - есть всего один join, который очеь редко вызывается. Но запросов много. И на их вызов тратится существенное время. Частично мы решаем проблему переносом даных SHM, но это не всегда удобно. Кстати, приложение в виде виртуалки лежит тут - http://freepcrf.com.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
void db_prepare() {
....
    res = PQprepare(conn, STMT_ID_SELECT1, Q_SELECT1, 0, NULL);
    CHECK_RESULT(res);
    PQclear(res);
....
}

void db_select1(int32_t* value) {
    if (debug) {
        fprintf(stderr, "db_select1()\n");
    }
    PGresult* res = PQexecPrepared(conn,
            STMT_ID_SELECT1,
            0,
            NULL,
            NULL,
            NULL,
            1);
    CHECK_RESULT(res);
    *value = -1;
    if (PQntuples(res) == 0) {
        fprintf(stderr, "db_select1() return no rows\n");
        if (exit_on_error) {
            exit(EXIT_FAILURE);
        }
    } else {
        *value = ntohl(*(int32_t *) PQgetvalue(res, 0, 0));
        if (debug) {
            fprintf(stderr, "db_select1() return %d\n", *value);
        }
    }
    PQclear(res);
}
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728739
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovЖоао!shared memory с tcp/ip.
Отлично! Как мне сравнить работу ODBC с PostgreSql через SHM или хотябы через сокет? Я собственно про это и пишу, что нет возможности выбрать правильный и быстрый способ подключения

Собственно проблема в том что тот режим использования базы который у вас получается не используется никем кроме вас (локальная In-memory db без конкурентного доступа... это совсем не то под что Postgresql его драйвера оптимизировали).
Все обсуждения о проблемах с производительностью PostgreSQL в моей практике начинались с уточнения "а случайно у вас приложение с базой не на одном сервере живет и если на одном давайте сначала по серверам разным разнесем а потом уже будем смотреть где и что тормозит".

C моей точки зрения штатный режим работы PostgreSQL это:
1)удаленный по TCP/IP
2)в кучу одновременно выполняемых запросов/активных соединений (~2xCPU cores на сервере)
3)всегда идущий активный IO (редко когда база только в памяти помещается)
(и в общем 95% баз с которыми я пересекался именно такие).

У вас же:
1)локальный доступ с приложением на том же сервере
2)1 поток
3)фактически чистый In-memory

Не удивительно что в таком режиме PostgreSQL сильно уступает специализированным in-memory решениям.

Если у вас вопрос в получении максимума TPS на ваших запросах то вам надо уходить от однопоточной модели работы с PostgreSQL.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728769
Фотография vromanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk,

Это только тест однопоточный. А так у нас вполне все себе конкурентное. Другое дело, что мы специально предпринимаем специальные усилия чтобы не было конфликтов при работе. Например, есть в базе информация относящаяся к какому-то пользователю и его активной сесси. Если уже обрабатывается запрос связанный с этим пользователем, то другие запросы связанные с ним задерживаются.
Сервера у нас в продакшене от 8 до 24-х ядер.
Вот такая у нас задача, и мы ее решаем :). Мы не можем поменять нашу задачу чтобы она лучше подходила под Posgresql :). Пока мы bcgjkmpetv posgresql для масштабирования вниз. Т.к. при большой нагрузке TT становится выгоднее просто экономически.
...
Рейтинг: 0 / 0
Глюки и низкая произодительность ODBC драйвера
    #38728849
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vromanovMaxim Boguk,

Это только тест однопоточный. А так у нас вполне все себе конкурентное. Другое дело, что мы специально предпринимаем специальные усилия чтобы не было конфликтов при работе. Например, есть в базе информация относящаяся к какому-то пользователю и его активной сесси. Если уже обрабатывается запрос связанный с этим пользователем, то другие запросы связанные с ним задерживаются.
Сервера у нас в продакшене от 8 до 24-х ядер.
Вот такая у нас задача, и мы ее решаем :). Мы не можем поменять нашу задачу чтобы она лучше подходила под Posgresql :). Пока мы bcgjkmpetv posgresql для масштабирования вниз. Т.к. при большой нагрузке TT становится выгоднее просто экономически.

на 24x ядерном сервере вы можете на простых запросах получить используя PostgreSQL где то 300.000-400.000 req/s (по тому что я тестировал)... это уже достаточный результ для многих применений.

PS: результаты TT over TCP/IP выглядят не особо радостно.
...
Рейтинг: 0 / 0
25 сообщений из 36, страница 1 из 2
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Глюки и низкая произодительность ODBC драйвера
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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