Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
Имеем таблицу в которой храниться около 3.5 милионов записей. В таблице есть один первичный ключ и кластерный btree индекс по нему (поле doc_id). Почему запрос select count(*) from docs1 и select count(doc_id) from docs1 выполняються порядка 5 минут? План запроса tests=# explain select count(doc_id) from docs1; QUERY PLAN ---------------------------------------------------------------------- Aggregate (cost=138072.83..138072.83 rows=1 width=4) -> Seq Scan on docs1 (cost=0.00..128869.06 rows=3681506 width=4) (2 rows) То есть делаться полные перебор, почему? Чего я делаю не так? PostgreSQL 8.0.3 for Windows на Win2k3 SE, на машине 2*1gHz Xeon'а и 1Гб ОЗУ, винт ATA66 7200rpm. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 17:02 |
|
||
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
пройдись поиском по "Count" и "индекс". Обсуждалось. ПРоблема в специфике индексов постгреса ( кажеца - в специфике индексов для версий - строится индекс для всех записей, а актуальность ("не удаленность") проверяется только в самой записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 20:17 |
|
||
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
А как еще можно посчитать количество записей в таблице, нежели чем полным перебором? И как к этому делу индекс привесить? В постгресе ни одна агрегатная функция не использует индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2005, 09:16 |
|
||
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
поиск рулитпройдись поиском по "Count" и "индекс". Обсуждалось. ПРоблема в специфике индексов постгреса ( кажеца - в специфике индексов для версий - строится индекс для всех записей, а актуальность ("не удаленность") проверяется только в самой записи. Я бы сказал - вообще в специфике индексов в любой БД. Индекс - это некая штука, которая позволяет тебе быстро найти ОДНУ конкретную строку. А число строк с индексом не связано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2005, 09:21 |
|
||
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
Кувалдин РоманА как еще можно посчитать количество записей в таблице, нежели чем полным перебором?Триггерами (при изменении кол-ва строк в таблице) поддерживать [системную] таблицу (table_id,rows_count). Кувалдин РоманВ постгресе ни одна агрегатная функция не использует индексов.В 8.1 min и max будут использовать индексы, ура! :) http://developer.postgresql.org/docs/postgres/release.html#RELEASE-8-1 Automatically use indexes for MIN() and MAX() (Tom) In previous releases, the only way to use an index for MIN() or MAX() was to rewrite the query as SELECT col FROM tab ORDER BY col LIMIT 1. Index usage now happens automatically. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2005, 09:36 |
|
||
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat Кувалдин РоманА как еще можно посчитать количество записей в таблице, нежели чем полным перебором?Триггерами (при изменении кол-ва строк в таблице) поддерживать [системную] таблицу (table_id,rows_count). Триггеры - в данном случае дополнительный механизм. Хочешь - делай сам системную таблицу, и реализуй его. В БД такую фичу засовывать нет надобности. Тем более что count по какому-либо условию, которое отсеивает некоторые строки из таблицы, сделает твое значение ненужным. Будешь хранить все возможные count-ы? select count(id) from table1 where id>100; select count(id) from table1 where id<100; select count(id) from table1 where id>200; select count(id) from table1 where id>50; select count(...) from table1 where ...; Кувалдин РоманВ постгресе ни одна агрегатная функция не использует индексов.В 8.1 min и max будут использовать индексы, ура! :) http://developer.postgresql.org/docs/postgres/release.html#RELEASE-8-1 Automatically use indexes for MIN() and MAX() (Tom) In previous releases, the only way to use an index for MIN() or MAX() was to rewrite the query as SELECT col FROM tab ORDER BY col LIMIT 1. Index usage now happens automatically.[/quot] Это называется "kernel hack". Кстати, min и max я всю жизнь так и делал. И не только в постгресе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2005, 10:45 |
|
||
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
Еще можно попробывать делать ANALYZE перед запросом. Может поможет :) Опять же где-то проскакивала ссылка на статью по типу "Настройка производительности Postgres" и там этот вопрос поднимался. На сколько я помню - что приблизительное количество строк можно получить из таблиц статистики. Сразу после ANALYZE это значение будет почти всегда точным. Почти - это если в промежутке кто-то успеет вставить лимон-другой записей :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2005, 11:19 |
|
||
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
Кувалдин РоманТем более что count по какому-либо условию, которое отсеивает некоторые строки из таблицы, сделает твое значение ненужным. Будешь хранить все возможные count-ы? select count(id) from table1 where id>100; select count(id) from table1 where id<100; select count(id) from table1 where id>200; select count(id) from table1 where id>50; select count(...) from table1 where ...;Зависит от задачи. Если что-то ОЛАПовидное, то буду. Кувалдин РоманКстати, min и max я всю жизнь так и делал. И не только в постгресе.Теперь появится для нас замечательный повод поглупеть, и писать просто select min(...). :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2005, 11:31 |
|
||
|
Производительность запроса count
|
|||
|---|---|---|---|
|
#18+
Кувалдин Роман поиск рулитпройдись поиском по "Count" и "индекс". Обсуждалось. ПРоблема в специфике индексов постгреса ( кажеца - в специфике индексов для версий - строится индекс для всех записей, а актуальность ("не удаленность") проверяется только в самой записи. Я бы сказал - вообще в специфике индексов в любой БД. не уверен. если бы, к примеру, индекс [каким-то раком] включал в себя только акутальные записи, то достаточно было бы прочитать только индекс, но не таблицу, что видимо было бы таки быстрее (просто по объему данных). Не помню точно, но кааца натыкался (в "сравнении") на упоминание об именно таком (т.е. позволяющем выяснить актуальность записи не тыкаясь в саму таблицу) устройстве индексов для какого-то из версионников. Что касается каунта по условию - дык задействуй условие заведомо юзающее индекс, и будет тибе щасье. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2005, 12:16 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=33273229&tid=2007012]: |
0ms |
get settings: |
6ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
101ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
35ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 412ms |

| 0 / 0 |
