ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Долгое время запроса count(*)
5 сообщений из 5, страница 1 из 1
Долгое время запроса count(*)
    #40031536
prustr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
prustr
Участник
Postgres 11
Есть таблица на 6 млн записей:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
CREATE TABLE public.rows_tidc
(
    id integer NOT NULL DEFAULT nextval('rows_id_seq'::regclass),
    cid smallint NOT NULL,
    ...,
    CONSTRAINT pk_rt PRIMARY KEY (id)
);
CREATE INDEX ixrt_cid ON public.rows_tidc USING btree
(cid ASC NULLS LAST);



выполняю запрос:
Код: sql
1.
2.
EXPLAIN (ANALYZE, BUFFERS) 
SELECT count(*) FROM public.rows_tidc;


План выполнения:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
"Finalize Aggregate  (cost=316143.96..316143.97 rows=1 width=8) (actual time=11231.133..11231.223 rows=1 loops=1)"
"  Buffers: shared hit=526 read=280894"
"  ->  Gather  (cost=316143.75..316143.96 rows=2 width=8) (actual time=11228.249..11231.196 rows=3 loops=1)"
"        Workers Planned: 2"
"        Workers Launched: 2"
"        Buffers: shared hit=526 read=280894"
"        ->  Partial Aggregate  (cost=315143.75..315143.76 rows=1 width=8) (actual time=11219.795..11219.803 rows=1 loops=3)"
"              Buffers: shared hit=526 read=280894"
"              ->  Parallel Seq Scan on rows_tidc  (cost=0.00..308399.00 rows=2697900 width=0) (actual time=0.061..6281.446 rows=2158320 loops=3)"
"                    Buffers: shared hit=526 read=280894"
"Planning Time: 0.502 ms"
"Execution Time: 11231.311 ms"



или такой запрос:
Код: sql
1.
2.
EXPLAIN (ANALYZE, BUFFERS) SELECT cid, count(*)
	FROM public.rows_tidc GROUP BY cid;


План выполнения:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
"Finalize GroupAggregate  (cost=322923.98..323083.09 rows=628 width=10) (actual time=13134.372..13146.043 rows=878 loops=1)"
"  Group Key: cid"
"  Buffers: shared hit=637 read=280797"
"  ->  Gather Merge  (cost=322923.98..323070.53 rows=1256 width=10) (actual time=13134.351..13140.559 rows=2475 loops=1)"
"        Workers Planned: 2"
"        Workers Launched: 2"
"        Buffers: shared hit=637 read=280797"
"        ->  Sort  (cost=321923.96..321925.53 rows=628 width=10) (actual time=13121.997..13123.199 rows=825 loops=3)"
"              Sort Key: cid"
"              Sort Method: quicksort  Memory: 63kB"
"              Worker 0:  Sort Method: quicksort  Memory: 64kB"
"              Worker 1:  Sort Method: quicksort  Memory: 63kB"
"              Buffers: shared hit=637 read=280797"
"              ->  Partial HashAggregate  (cost=321888.50..321894.78 rows=628 width=10) (actual time=13116.325..13120.411 rows=825 loops=3)"
"                    Group Key: cid"
"                    Buffers: shared hit=623 read=280797"
"                    ->  Parallel Seq Scan on rows_tidc  (cost=0.00..308399.00 rows=2697900 width=2) (actual time=0.056..6620.894 rows=2158320 loops=3)"
"                          Buffers: shared hit=623 read=280797"
"Planning Time: 0.197 ms"
"Execution Time: 13147.295 ms"



Тоже самое на том же компе, на аналогичной таблице в 10 млн записей (почти в 2 раза больше), но в mysql
Код: sql
1.
2.
3.
4.
5.
SELECT count(*)  FROM `data`
Запрос занял менее 1 сек 

id 	select_type 	table 	type 	possible_keys 	key 	key_len 	ref 	rows 		Extra 	
1 	SIMPLE 			data 	index 	NULL			fk_cid 	5 			NULL	9545731 	Using index



Код: sql
1.
2.
3.
4.
5.
SELECT category_id, count( * ) FROM data GROUP BY category_id
Запрос занял 3.6783 сек.

id 	select_type 	table 	type 	possible_keys 	key 	key_len 	ref 	rows 	Extra 	
1 	SIMPLE			data 	index 	fk_cid 			fk_cid 	5 			NULL	5479000 Using index



По второму запросу постгрес проигрывает mysql 10 сек! Что с ним не так? Очень не хочется слезать с postgrest...
...
Рейтинг: 0 / 0
27.12.2020, 11:27
| Ответить | Цитировать | Написать  
Долгое время запроса count(*)
    #40031554
prustr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
prustr
Участник
Ситуация исправилась после
Код: sql
1.
2.
3.
4.
5.
6.
VACUUM ANALYZE  rows_tidc;

SELECT cid, count(*)
	FROM public.rows_tidc GROUP BY cid;
Successfully run. Total query runtime: 1 secs 136 msec.
878 rows affected.



но analyzer время подвирает конкретно:))
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
"Finalize GroupAggregate  (cost=1000.46..144979.99 rows=627 width=10) (actual time=13.475..11179.848 rows=878 loops=1)"
"  Group Key: cid"
"  ->  Gather Merge  (cost=1000.46..144967.45 rows=1254 width=10) (actual time=12.669..11174.034 rows=1886 loops=1)"
"        Workers Planned: 2"
"        Workers Launched: 2"
"        ->  Partial GroupAggregate  (cost=0.43..143822.68 rows=627 width=10) (actual time=4.281..9170.330 rows=629 loops=3)"
"              Group Key: cid"
"              ->  Parallel Index Only Scan using ixrt_cid on rows_tidc  (cost=0.43..130337.16 rows=2695851 width=2) (actual time=0.058..4976.898 rows=2158320 loops=3)"
"                    Heap Fetches: 0"
"Planning Time: 0.157 ms"
"Execution Time: 11181.294 ms"


ну и ладно, мне же ехать, а не шашечки
...
Рейтинг: 0 / 0
27.12.2020, 12:30
| Ответить | Цитировать | Написать  
Долгое время запроса count(*)
    #40031556
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
prustr,

планировщик время не планирует, вообще. cost — просто число для сравнения разных планов.
...
Рейтинг: 0 / 0
27.12.2020, 12:32
| Ответить | Цитировать | Написать  
Долгое время запроса count(*)
    #40031559
prustr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
prustr
Участник
vyegorov,
Вообще то я про Execution Time: 11181.294 ms
...
Рейтинг: 0 / 0
27.12.2020, 12:36
| Ответить | Цитировать | Написать  
Долгое время запроса count(*)
    #40031569
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
prustr
vyegorov,
Вообще то я про Execution Time: 11181.294 ms


1)я бы включил set track_io_timing to on;
и потом гонял бы EXPLAIN (ANALYZE, COSTS, BUFFERS, TIMING) запроса
причем не 1 раз а 3-4-5 смотря на изменение времени работы

у вас явно зависит от везения и от того насколько данные с памяти (shared buffers базы или кеша OS) читаются а насколько с дисков.

Скорее всего диски у вас очень неторопливые и 1000 раз сходить на диск - вот 10 секунд и набирается...
а следующий раз все эти данные уже в памяти лежат и скорость совсем другая получается.

В общем когда у вас база не в памяти а сильно с дисков читается скорость запроса будет определяться
1)скоростью работы дисков
2)везением зависящим от того насколько нужные вам данные закешированы


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
27.12.2020, 13:42
| Ответить | Цитировать | Написать  
5 сообщений из 5, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Долгое время запроса count(*)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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