статья о настройке производительности PostgreSQL

[Fiva]

Меня вот что интересует в данном вопросе:
Использование SELECT count(*) FROM <огромная таблица>
В статье, а так же на конференции было сказано что будет перебираться вся таблица, и как вариант решения предлагалось использовать вспомогательную таблицу. Так вот, как будет вести себя postgre в следующих случаях:
1. SELECT count(*) FROM <огромная таблица> WHERE field>0
где field - автоинкрементное поле - первичный индекс
2. SELECT count(*) FROM <огромная таблица> WHERE field=0 где field - проиндексированное значение, вспомогательное поле, устанавливаемое всегда по дефолту в 0
3. SELECT count(*) FROM <огромная таблица> GROUP BY field
где field - проиндексированное значение, вспомогательное поле, устанавливаемое всегда по дефолту в 0
4. SELECT sum(field) FROM <огромная таблица> GROUP BY field
где field - проиндексированное значение, вспомогательное поле, устанавливаемое всегда по дефолту в 1
я не сильно знаком с семантикой запросов postgre, мне ближе mysql но я думаю общий смысл моего вопроса понятен: будет ли использоваться в данном случае индекс

 

[nickg]

Во-первых, Postgres, а не Postgre. Привыкайте.
Во-вторых, индекс, возможно, сканироваться будет, но время, я думаю, будет сравнимым с полным сканированием таблицы.
В-третьих, в версии 8.1 count будет оптимизирован. Так что, главное -- выбрать "правильную" СУБД. И в ней все будет хорошо .

 

[fixxxer]

>Так вот, как будет вести себя postgre в следующих случаях:

EXPLAIN ANALYZE религия запрещает сделать?

 

[Fiva]

религия запрещает сделать хотя бы лишь потому, что вопрос был теоретическим, так как постгрес не юзаю. Проводить аналогию с mysql некорректно, так как там, афаик, count оптимизирован. Все таки хотелось бы услышать мнение докладчика на конференции (Борзов Алексей), так как он, насколько я помню, сказал, что при использовании в WHERE индексных полей запрос значительно упроститься и ускорится.

 

[Sad Spirit]

Автор оригинала: Fiva
религия запрещает сделать хотя бы лишь потому, что вопрос был теоретическим, так как постгрес не юзаю.

на "теоретический" вопрос "теоретический" ответ --- а хрен его знает.

смысл приведённых запросов я, честно говоря, вообще понять не могу.

Проводить аналогию с mysql некорректно, так как там, афаик, count оптимизирован.

ну да, count там конечно оптимизирован, но ты попробуй его погонять на таблицах типа InnoDB.

Все таки хотелось бы услышать мнение докладчика на конференции (Борзов Алексей), так как он, насколько я помню, сказал, что при использовании в WHERE индексных полей запрос значительно упроститься и ускорится.

не говорил я такого! повторю-ка основные тезисы, кое-что из них я излагал уже на кофе-брейке после доклада.

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

select count(*) from foo;

в разных параллельно работающих транзакциях может вернуть совершенно разные значения.

информация о видимости есть только в собственно файле таблицы, в индексе её нету.

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

если нужно получить количество записей в небольшой части таблицы, то индекс вполне себе может использоваться.

если добавить в индекс информацию о видимости записи, то индекс станет больше по размеру и труднее в обработке, то есть выигрывая на запросах, где нам нужны только данные, имеющиеся в индексе, мы проиграем на всех остальных.

Автор оригинала: nickg
В-третьих, в версии 8.1 count будет оптимизирован.

а можно грязные подробности? а то про оптимизацию min() / max() я читал (и на конференции рассказывал), а про count() --- нет.

 

[neko]

[прочел невнимательно]

 

[Vetal]

Автор оригинала: MiRacLe
Оптимизация PostgreSQL

таблица 85тыс строк, 15 полей
удалил OID
стало в два раза дольше

 

[Romkapost]

ссылка со статьёй битая, pdf после скачивания тоже, подскажите плиз где можно прочитать эту статью

 

[Sad Spirit]

Автор оригинала: Romkapost
ссылка со статьёй битая, pdf после скачивания тоже, подскажите плиз где можно прочитать эту статью

Поправил ссылки, дело было в том, что "детали" переехали на домен phpclub.ru

 

[dr-sm]

пропеарю тут, неплохой текст
Работа с Postgresql: настройка, масштабирование
Автор: Васильев Алексей

 

[Sad Spirit]

Автор оригинала: dr-sm
пропеарю тут, неплохой текст
Работа с Postgresql: настройка, масштабирование
Автор: Васильев Алексей

Открыл --- товарищ практически скопипастил у меня введение (ссылка-то есть, но копировать текст абзацами всё равно неправильно).
Не знаю, каким образом написана остальная часть статьи, но закрадываются подозрения...