GeoMapX

Как один из вариантов оптимизации скорости выборки может быть использована денормализация таблиц. Продолжим работать с тем же тестовым распределением, но теперь в таблице фактов заменим числовые ключи на строковые значения, соответствующие значениям из справочников. Для генерации тестового распределения использована приведенная ниже функция, создающая строки из символа "0", повторенного случайное число раз от нуля до заданного аргументом значения. Для вычисления времени выполнения запроса на этот раз использую команду explain analyze, хотя имхо она дает заниженное значение времени. Количество возвращаемых строк также можно увидеть в выводе названной команды, но из соображений удобства привожу и результат запроса на получение числа строк. Параметры сервера: Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz MemTotal: 8310900 kB Параметры сервера PostgreSQL: work_mem = 100000 # min 64, size in KB maintenance_work_mem = 2000000 # min 1024, size i

Цель данного тестирования - проверить работу в SQLite тестов, написанных при тестировании PostgreSQL и убедиться, какая из СУБД более подходит для работы с большими БД. Параметры сервера/Server parameters: Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz MemTotal: 8310900 kB Параметры БД SQLite/SQLite parameters: sqlite> pragma page_size; 4096 sqlite> pragma cache_size; 400000 Размер кэша выбран равный использованному при тестировании PostgreSQL (в рассматриваемых СУБД используются разные размеры страниц, поэтому кэш в обоих случаях 1,6 Gb, хотя абсолютные значения параметров отличаются). Функция intrange2table, используемая для создания тестового распределения, предоставляется одним из расширений, доступных в deb-пакете , а также в исходных текстах . The SQLite cache size is equal to PostgreSQL cache size. The PostgreSQL databases are using 8 kB page size by default. SQlite cache size is measured in pages (4kB in my configuration) but not on kilobytes. The intrange2table()

В очередной раз "ввязался" в дискуссию о разработке больших баз данных на СУБД PostgreSQL. В ходе обсуждения появилась необходимость провести численные измерения скорости выполнения запросов на базах разного масштаба. Так же обнаружилось, что в PostgreSQL 8.3 планировщик работает получше, но принципиальной разницы нет, т.к. того же самого поведения можно добиться и в 8.1. Выполнено: Проверил 1 М, 10 М и 100 М записей с тремя индексами (запрос по 4-м полям, но каждый раз использовалось только 3 индекса). Размер выборки во всех случаях был практически идентичный. Для того, чтобы заставить постгрес пользоваться индексами, были подобраны параметры тестового распределения. При 100 М записей постгрес не смог создать индекс после вставки всех записей, требуя больше памяти, потому индексы создавались до вставки. Время измерено в pgadmin, все запросы работали по "горячему кэшу", т.е. запускались несколько раз подряд до стабилизации времени выборки (для 100 М таблицы первые 3

Для кэширования статичного контента в AOL Server можно использовать такую технику: rename ::html::menu ::html::menu_orig proc ::html::menu {current} { with-adp-cache mainmenu,$current [list ::html::menu_orig $current] } Здесь мы оборачиваем функцию ::html::menu в кэширующий блок, переименовывая оригинальную функцию. Сама реализация кэширующей функции может быть такой: proc with-adp-cache {key script} { if {[info procs ns_adp_puts] ne {}} { uplevel 1 $script return } if {[nsv_exists ns_adp_cache $key] == 1} { ns_adp_puts [nsv_get ns_adp_cache $key] return } set result [with-adp-return $script] if {[nsv_exists ns_adp_cache $key] == 0} { nsv_set ns_adp_cache $key $result } ns_adp_puts $result } proc with-adp-return {script} { if {[info commands ns_adp_puts_orig] eq {}} { rename ns_adp_puts ns_adp_puts_orig rename _ns_adp_puts ns_adp_puts } uplevel 1 $script if