Хорошо, я ценю, что вопрос немного расплывчатый, но после дня поиска в гугле я ничего не получаю, любая помощь будет оценена, и я готов попробовать что угодно.
Проблема в том, что у нас есть база данных PostgreSQL, которая содержит 10-15 миллионов строк в конкретной таблице.
Мы делаем выбор для всех столбцов на основе поля DateTime в таблице. Нет объединений, просто стандартный выбор с предложением where (время> = x и время <= y). На поле также есть индекс ... </p>
Когда я выполняю sql с использованием psql на локальном компьютере, он запускается примерно через 15-20 секунд и возвращает 0,5 миллиона строк, одна из которых представляет собой текстовое поле, содержащее большой объем данных на строку (программа трассировки стека). Когда мы используем тот же sql и запускаем его через Npgsql или pgadmin III в Windows, это занимает около 2 минут.
Это наводит меня на мысль, что это проблема сети. Я проверил на компьютере, когда запрос выполняется, и он не использует огромный объем памяти или ЦП, а скорость сети незначительна.
Я также ознакомился с рекомендациями на сайте Postgres для настроек памяти. включая обновление shmmax и shmall.
Это Ubuntu 10.04, PSQL 8.4, 4 ГБ ОЗУ, Quad Xeon 2,8 ГГц (виртуальные, но выделенные ресурсы). на машине также есть аналог Windows (2008 R2, SS2008), но он выключен. Запрос возвращается через 10-15 секунд, используя SS с той же схемой и данными, я знаю, что это не будет прямым сравнением, но хотел показать, что это не проблема производительности диска.
Так что вопрос ... есть предложения? Существуют ли какие-либо сетевые настройки, которые я должен изменить? Что-нибудь, что я пропустил? Я не могу дать слишком много информации о базе данных, но вот ОБЪЯСНИТЕЛЬНЫЙ АНАЛИЗ, который запутан ...
Index Scan using "IDX_column1" on "table1" (cost=0.00..45416.20 rows=475130 width=148) (actual time=0.025..170.812 rows=482266 loops=1)
Index Cond: (("column1" >= '2011-03-14 00:00:00'::timestamp without time zone) AND ("column1" <= '2011-03-14 23:59:59'::timestamp without time zone))
Total runtime: 196.898 ms