PSQL = быстрый, удаленный sql = v.slow - PullRequest
Новая
       26

PSQL = быстрый, удаленный sql = v.slow

1 голос
/ 24 марта 2011

Хорошо, я ценю, что вопрос немного расплывчатый, но после дня поиска в гугле я ничего не получаю, любая помощь будет оценена, и я готов попробовать что угодно.

Проблема в том, что у нас есть база данных 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

1 Ответ

0 голосов
/ 24 марта 2011

Попробуйте установить cursor_tuple_fraction в 1 в psql и посмотрите, изменит ли это результаты. Если это так, то вполне вероятно, что оптимизатор выбирает лучший план, основанный только на получении первых 10% или более результатов по сравнению с получением всей партии. Istr psql использует курсор для извлечения результатов по частям, а не метод «firehose» executequery.

Если это так, то это не указывает непосредственно на решение, но вам нужно настроить параметры планировщика, и, по крайней мере, если вы сможете воспроизвести поведение в psql, чем будет легче увидеть различия и тестовые изменения.

...