Продолжаю публикацию тестов.

PostgreSQL 8.1 vs. SQLite 3.6.20 in real application

Вероятно, в следующей статье будет описана технология он-лайн бэкапа эскулайт баз на основе лога запросов на основе возможностей версии 3.6.21 (планируемая дата релиза 5-го декабря). Задача состоит в повышении надежности системы, распределение нагрузки рассматривать не будем.228

Dmitry ArefievПро статью вопросЫ. Не описано (лишь догадываться остается):
- среда исполнения запросов;
- сколько записей каждый запрос должен возвратить;
- что за время мерилось;
- что там со статистикой;
- расположены файлы БД на одном носителе или на разных;
- кэш файловой системы / СУБД холодный или горячий;
- и т.д.

PostgreSQL - это может быть время исполнения запроса и возврата всех записей.
SQLite - время до возврата первой записи.

Что ж вы так невнимательно читаете... Все есть, все сказано:

1. Указано ."timer on", а с точки начинаются команды эскулайт шелла. Ни в каких врапперах этих команд нет, поскольку имплементированы они именно в коде шелла эскулайт.
2. Приведен explain analyze в постгресе, в котором кол-во возвращаемых записей подсчитывается:


Т.е. первый запрос вернет 1 строку, а второй - 33.

3. Сказано, что измерялось время встроенным таймером в эскулайт и командой explain analyze в постгресе. Смотрим "man time"
В документации постгреса сказано, что explain analyze вернет реальное время, опять же, обратимся к man time

Постгрес не считает время на передачу данных клиенту, т.к. это время не может быть посчитано самой СУБД. Показывается время извлечения данных, притом нужно учесть, что для большого кол-ва записей может потребоваться еще дополнительно значительное время на их передачу клиенту. Эскулайт исполняется в процессе приложения, потому извлеченные данные сразу же доступны клиенту, не требуется их куда-либо передавать.

Поясню на примере:
Здесь 14 мс - время на выборку, передачу данных клиенту и вывод их на консоль. Процессор многоядерный, потому real < user+sys.

4. Постгрес о наличи своей статистики отрапортовал. Притом, поскольку реальный результат совпал с ожидаемым (см. explain analyze), известно, что статистика актуальная. В эскулайте без разницы, была собрана статистика командой analyze или нет, потому и не упоминается.
5. В "Hardware" указан 1 диск, на нем все и расположено. А где же еще. Есть еще системный диск и проч., но в тестах они не участвуют, потому и не упоминаются.
6. Для эскулайт время sys как раз показывает заполнение кэша ФС, если кэш "горячий", то это время равно 0. В постгресе кэш горячий, т.к. ясно сказано, что это _рабочая_ система.

Дополнил статью о проблеме с падением скорости создания индексов:
Degradation of indexing speed in SQLite 3.6.20

Теперь ясно, как посчитать объем ОЗУ, нужный для быстрого создания индекса на большую таблицу. Например, для индексирования по одному полю таблицы на 100 миллионов записей потребуется разрешить использование 1 Gb ОЗУ для эскулайт. Еще интересный вопрос с единичными вставками в большие уже индексированные таблицы, но с этим пока не все ясно, могу лишь сказать, что на той же таблице в 100 М записей на единичную вставку требуется уже около 18 мс и при увеличении размера таблицы скорость вставки падает приблизительно линейно, причем от размера кэша зависимости нет. С выборками проблем не вижу.