ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / select count(*) from t - как быстрее получить прибл.к-во
13 сообщений из 38, страница 2 из 2
  2  все
select count(*) from t - как быстрее получить прибл.к-во
    #34763911
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_v13
Гость
LeXa NalBat
По видимому, разработчики ПГ наконец услышали глас юзеров своей базульки и таки научили планировщик таким элементарным финтам, как использование существующего primary key для count.

Я только пока не могу перебраться на версию старше 8.1.3 - импорт/экспорт базы в ~100 ГБ с последующим vacuum analyze это дофига времени... Бизнес не ждет. До нового года откладываю.
...
Рейтинг: 0 / 0
30.08.2007, 11:36
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765096
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
alex_v13 LeXa NalBat
По видимому, разработчики ПГ наконец услышали глас юзеров своей базульки и таки научили планировщик таким элементарным финтам, как использование существующего primary key для count.


Попробую сформулировать максимально математично.
Для отработки count() PG должен просмотреть ВСЕ записи попадающие под условие count().
Если эти записи целесообразно получать из индекса (например условие в WHERE), то он может исопльзоться, если нет (SELECT count(*) FROM my_big_table_gigi) - то будет SEQSCAN.
В любом случае, будет проверена КАЖДАЯ строчка. И сама аггрегатная функция count() не может использовать индекс. Он может быть использован только для получения строк. Аггрегатные функция max/min - могут использовать индекс.

Напомню, в индексе PG нет условий видимости записи для текущей транзакции, как следствие - индекс не может использоваться для определения точного количества строк. Что не мешает использовать его для других, не связанных с подсчетом строк задач в рамках этого же запроса.

ЗЫ Вроде похоже на правду
...
Рейтинг: 0 / 0
30.08.2007, 15:44
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765247
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_v13
Гость
Теория-то понятна и очевидна: я же написал "использование существующего primary key для count", а не "count по индексу" :) Так что все справедливо.
Но вот 8.1.3 для count по таблицам любого размера выдает у меня SeqScan, в то время как 8.2.4 таки выдает IndexScan.
...
Рейтинг: 0 / 0
30.08.2007, 16:17
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765457
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
alex_v13Теория-то понятна и очевидна: я же написал "использование существующего primary key для count", а не "count по индексу" :) Так что все справедливо.
Но вот 8.1.3 для count по таблицам любого размера выдает у меня SeqScan, в то время как 8.2.4 таки выдает IndexScan.
Ничего не понял :( стихи?

провел тест уважаемого LeXa NalBat :

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
Welcome to psql  8 . 1 . 4 , the PostgreSQL interactive terminal.
test=# explain select count(*) from t1 where id between  100  and  200 ;
                                QUERY PLAN
--------------------------------------------------------------------------
 Aggregate  (cost= 4 . 85 .. 4 . 86  rows= 1  width= 0 )
   ->  Index Scan using t1_pkey on t1  (cost= 0 . 00 .. 4 . 60  rows= 100  width= 0 )
         Index Cond: ((id >=  100 ) AND (id <=  200 ))
( 3  rows)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
Welcome to psql  8 . 2 . 4 , the PostgreSQL interactive terminal.
test=# explain select count(*) from t1 where id between  100  and  200 ;
                                QUERY PLAN
---------------------------------------------------------------------------
 Aggregate  (cost= 10 . 50 .. 10 . 51  rows= 1  width= 0 )
   ->  Index Scan using t1_pkey on t1  (cost= 0 . 00 .. 10 . 25  rows= 100  width= 0 )
         Index Cond: ((id >=  100 ) AND (id <=  200 ))
( 3  rows)

ну и в чем разницо?
...
Рейтинг: 0 / 0
30.08.2007, 17:03
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765561
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_v13
Гость
Возможно дело в специфике моей базы - маленькие таблицы с большим количеством UPDATE и очень большие с массовыми INSERT - т.е. или много версий записей или много данных не влезающих в память - понятно, что планировщик выбирает SeqScan.
...
Рейтинг: 0 / 0
30.08.2007, 17:24
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765573
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Andrey Daeronну и в чем разницо?OFFTOPIC

cost=4.85..4.86

cost=10.50..10.51

8.2.4 в два раза медленнее :-)
...
Рейтинг: 0 / 0
30.08.2007, 17:26
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765585
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_v13
Гость
А 8.2.4 я проверял на свеже-восстановленной из дампа базе, после VACUUM FULL ANALYZE в которой лишних версий записей и пустых страниц нема - отсюда разница.
...
Рейтинг: 0 / 0
30.08.2007, 17:28
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765618
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
alex_v13или много данных не влезающих в памятьПамять тут ни при чем. Ни для SecScan, ни для IndexScan она не нужна.
...
Рейтинг: 0 / 0
30.08.2007, 17:37
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765675
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
LeXa NalBat Andrey Daeronну и в чем разницо?OFFTOPIC

cost=4.85..4.86

cost=10.50..10.51

8.2.4 в два раза медленнее :-)
вот-вот!!!!
...
Рейтинг: 0 / 0
30.08.2007, 17:47
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765701
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_v13
Гость
LeXa NalBat alex_v13или много данных не влезающих в памятьПамять тут ни при чем. Ни для SecScan, ни для IndexScan она не нужна.

Тогда в shared_buffers оставим как есть по умолчанию, не помню сколько - 1000?

Выбор плана завист не только от предполагаемой ПГ ситуации с данным в таблице, но и от доступных ресурсов, чему я был свидетелем неоднократно.
...
Рейтинг: 0 / 0
30.08.2007, 17:54
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765781
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
alex_v13Тогда в shared_buffers оставим как есть по умолчанию, не помню сколько - 1000?Возможно, для некоторой, при этом большой и серьезной, задачи большой shared_buffers не нужен.

alex_v13Выбор плана завист не только от предполагаемой ПГ ситуации с данным в таблице, но и от доступных ресурсов, чему я был свидетелем неоднократно.Насколько я понял из доки, выбор плана зависит исключительно от статистики по таблицам и параметров описанных в главе 17.6. доки.

На тест, иллюстрирующий вляние параметра shared_buffers (или других) на план запроса, хотелось бы взглянуть.
...
Рейтинг: 0 / 0
30.08.2007, 18:10
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34765822
alex_v13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_v13
Гость
Например, вот цитата из доки:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
effective_cache_size (floating point)

Sets the planner’s assumption about the effective size of the disk cache that is available to a single
index scan. This is factored into estimates of the cost of using an index; a higher value makes it
more likely index scans will be used, a lower value makes it more likely sequential scans will
be used. When setting this parameter you should consider both PostgreSQL’s shared buffers and
the portion of the kernel’s disk cache that will be used for PostgreSQL data files. Also, take into
account the expected number of concurrent queries using different indexes, since they will have
to share the available space. This parameter has no effect on the size of shared memory allocated
by PostgreSQL, nor does it reserve kernel disk cache; it is used only for estimation purposes.
The value is measured in disk pages, which are normally  8192  bytes each. The default is  1000 .

авторa higher value makes it
more likely index scans will be used, a lower value makes it more likely sequential scans will
be used.

Это я так понимаю ключевое место всей фразы.
...
Рейтинг: 0 / 0
30.08.2007, 18:20
| Ответить | Цитировать | Написать  
select count(*) from t - как быстрее получить прибл.к-во
    #34766039
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Effective_cache_size является параметром оптимизатора и не влияет больше ни на что, он описан в главе 17.6.
...
Рейтинг: 0 / 0
30.08.2007, 20:03
| Ответить | Цитировать | Написать  
13 сообщений из 38, страница 2 из 2
  2  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / select count(*) from t - как быстрее получить прибл.к-во
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]