Помните тему о UUID?

Ну вот, видно, что тормозит. ))))))))))))))

Reading 'uuid': 2.859 sec
Reading 'int': 9.188 sec

WAIT, OH SHI...

Так как в принципе выполение этого кода - малый процент от всего кода, то я имел ввиду медленнее на порядок. Если нет, то мне подходит

Большое спасибо за исследование, мне оно как раз актуально.

Вместо спасибо я бы попросил запустить прогу один раз у себя и скинуть результат )

С удовольствием, если расскажешь, как это сделать (с Java не знаком, PostgreSQL стоит).

Это исследование специфичное для pure-java базы H2. Его нужно переделывать для Postgre. Если у тебя Linux, то тебе нужно установить Maven, распаковать архив по ссылке и выполнить ту команду которую я написал в топике. Maven остально сделает за тебя, скачает все плагины, все библиотеки, скачает СУБД, соберет программу, запустит СУБД, запустит программу, результаты будут выведены в консоль.

«Необходимо скачать 122 MБ архивов.» брррр...

Ща переделаю на Python, SQLAlchemy и PostgreSQL

Ну у вас я так понимаю вообще Java не стоит. Ну пропробуйте. Интерестно посмотреть как будет на PostgreSQL. Только может лучше не надо через ORM, будет оверхед не связанный с вопросом?

Мне интересно именно с ORM. К тому же сомневаюсь, что ORM внесёт существенную разницу.

Итак, воспроизвёл. Схема базы такая же, но добавил 3ю таблицу, где UUID хранился в VARCHAR. Используется UUID версии 1. В качестве бесполезной нагрузки в последнее поле записывался 1 кБ букв «X». Код не привожу, так как он сильно завязан на мой рабочий проект. Количество записей уменьшил.

Режим работы ORM - без autocommit. Вставка тестируется 2 раза: в первый всё добавляется одним блоком, ORM группирует вставки, в второй раз после каждой вставки делается flush.

Использовалось: PostgreSQL 8.4, Python 2.7.1, Psycopg2 2.4.1, SQLAlchemy 0.6.7.

Результаты:

$ /opt/ibd3/bin/python test.py 
Scheduling main function
Running reactor
Initializing RDBMS
Creating classes
Generating data
Inserting without flush (total count: 10000)
- INT: 4.375206 sec.
- Native UUID: 4.834080 sec.
- VARCHAR UUID: 4.819657 sec.
Inserting with flush (total count: 10000)
- INT: 90.772417 sec.
- Native UUID: 91.859727 sec.
- VARCHAR UUID: 92.680923 sec.
Reading results (total count: 10000)
- INT: 11.621372 sec.
- Native UUID: 12.285052 sec.
- Native UUID: 12.496054 sec.
Reactor stopped

Принципиальной разницы между INT и UUID, а также между «родным» UUID и просто VARCHAR я не вижу.

Поправка: с autocommit.

Можно сделать вывод что ему пофиг на тип в обеих БД, так как боттлнек не в этом. Так как естественно что 128 бит эфективнее VARCHAR. Наверное просто разница именно на этой операции несоизмерима с главной нагрузкой IO или чего-то еще. Вообще у вас как-то намного медленнее получается. У меня то embedded и H2 и так быстрее PostgreSQL если не надо сильно масштабировать, но похоже SQLAlchemy у вас дает какой-то неадекватный оверхед

У меня не было пакетного добавления. Но в моем алгоритме самой программы таки мало этого будет.

Тут надо делать поправку на Python ещё. Ну и на прочие непредвиденные вещи. Вот, например, насчёт «128 бит эффективнее VARCHAR»: Postgres всё равно всё в строку переводит.

Так или иначе, для моих задач это подходит с избытком,

Ну там строка короче )

Вообще согласно бенчмаркам H2 во встроенном режиме, тоесть без оверхеда на связь быстрее в 10 раз чем PostgreSQL. Если в клиент-серверном, то меньше чем в полтора раза быстрее. Потому может быть таки боттл на связи