Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / ускорение выполнения запроса SELECT COUNT / 16 сообщений из 16, страница 1 из 1
19.07.2006, 17:34
    #33864887
twistfire
twistfire
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
В веб-приложении (пхп) используются запросы вида
SELECT COUNT(*) FROM sometable;

они жутко тормозят приложение
(запрос выполняется 6-7 секунд)

Можно ли как-то увеличить скорость выполнения запроса, возможно нужно просто как-то изменить запрос на более уместный?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.07.2006, 17:52
    #33864958
ChameLe0n
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Неоднократно здесь писали. Пользуйся поиском.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.07.2006, 18:18
    #33865078
twistfire
twistfire
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
странно - ничего не нашел - ничего кроме сравнения count(1) count(*)

Может что-то еще?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.07.2006, 05:35
    #33865591
Владимор Конев
Владимор Конев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
twistfireВ веб-приложении (пхп) используются запросы вида
SELECT COUNT(*) FROM sometable;

они жутко тормозят приложение
(запрос выполняется 6-7 секунд)

Можно ли как-то увеличить скорость выполнения запроса, возможно нужно просто как-то изменить запрос на более уместный?Что за таблица? Сколько в ней записей? Индексы по таблице есть?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.07.2006, 06:58
    #33865617
ChameLe0n
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Странно как-то искал.... Например:
/topic/216436&hl=count
/topic/251251&hl=count
/topic/227461&hl=count
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.07.2006, 07:03
    #33865621
ChameLe0n
ChameLe0n
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
авторЧто за таблица? Сколько в ней записей? Индексы по таблице есть?
Какое отношение к запросу с COUNT имеют индексы?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.07.2006, 07:05
    #33865623
Владимор Конев
Владимор Конев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
ChameLe0n авторЧто за таблица? Сколько в ней записей? Индексы по таблице есть?
Какое отношение к запросу с COUNT имеют индексы?Теперь уже никакого.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.07.2006, 13:26
    #33866945
twistfire
twistfire
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Все равно не понимаю.
Как у Sad Spirit
получилось
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Добро пожаловать в psql  7 . 4 . 7  - Интерактивный Терминал PostgreSQL.

Наберите:  \copyright для условий распространения
           \h для подсказки по SQL командам
           \? для подсказки по внутренним slash-командам (\команда)
           \g или ";" для завершения и выполнения запроса
           \q для выхода

template1=# explain select count(*) from pg_class where relname='pg_class';
                                           QUERY PLAN                           
-------------------------------------------------------------------------------------------------
 Aggregate  (cost= 5 . 55 .. 5 . 55  rows= 1  width= 0 )
   ->  Index Scan using pg_class_relname_nsp_index on pg_class  (cost= 0 . 00 .. 5 . 55  rows= 1  width= 0 )
         Index Cond: (relname = 'pg_class'::name)

у меня получается
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
shop=# EXPLAIN SELECT count(*) FROM shop_goods WHERE id> 0 ;
                              QUERY PLAN
-----------------------------------------------------------------------
 Aggregate  (cost= 25409 . 88 .. 25409 . 88  rows= 1  width= 0 )
   ->  Seq Scan on shop_goods  (cost= 0 . 00 .. 25385 . 58  rows= 9722  width= 0 )
         Filter: (id >  0 )
( 3  rows)
хотя поле ид - SERIAL PRIMARY KEY
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
shop-# \di
                     List of relations
 Schema |       Name       | Type  |   Owner   |   Table
--------+------------------+-------+-----------+------------
 public | points           | index | twistfire | shop_goods
 public | shop_cats_pkey   | index | netgen    | shop_cats
 public | shop_goods_catid | index | twistfire | shop_goods
 public | shop_goods_pkey  | index | netgen    | shop_goods
( 4  rows)

Что я делаю не так?
Возможно нужно использовать триггеры, это не отразится на скорости работы веб-приложения?
Как написать такой триггер - покажите пример пожалуйста.
Заранее спасибо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.07.2006, 14:21
    #33867193
Кувалдин Роман
Кувалдин Роман
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Скорее всего у тебя очень много ID>0. Соответственно, веса планов для SEQ_SCAN и INDEX_SCAN одинаковые. Планировщику проще перелопатить таблицу, нежели перелопачивать индекс, и для каждого узла лезть в таблицу и доставать оттуда строку.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.07.2006, 11:16
    #33869234
twistfire
twistfire
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
posovetovali ispolzovat sistwmnie tablici....
ia ne zneu kakim makarom - est chto-li dannie o kolichestve zapisei v opredelennih tablicah?

esli ispolzovat triggeri - kak luchshe organizovat rabotu s usloviami (WHERE)?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
20.07.2015, 19:13
    #39011689
Sufir
Sufir
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT
	count(*)
FROM
	"th"."ticket" AS "self"
	 JOIN "th"."user_question" AS "question" ON question.id = self.id
WHERE
	self.status = 1 AND question.trash = FALSE



Explain:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
Aggregate  (cost=77913.98..77913.99 rows=1 width=0) (actual time=210.591..210.591 rows=1 loops=1)
  ->  Nested Loop  (cost=0.00..77861.94 rows=20816 width=0) (actual time=0.133..204.154 rows=21276 loops=1)
        ->  Index Scan using idx_th_ticket_status on ticket self  (cost=0.00..12774.44 rows=20816 width=4) (actual time=0.063..58.075 rows=21280 loops=1)
              Index Cond: (status = 1)
        ->  Index Scan using pk_th_user_question on user_question question  (cost=0.00..3.11 rows=1 width=4) (actual time=0.005..0.006 rows=1 loops=21280)
              Index Cond: (id = self.id)
              Filter: (NOT trash)
Total runtime: 240.652 ms



Четыре запроса - уже секунда, плюс десяток других, "лёгких" запросов, плюс отработка скрипта и уже полторы-две секунды на формирование страницы. Это очень много. Прегенерация не вариант, т.к. два десятка различных фильтров, на все комбинации не нагенеришь. Джойнов тоже может прибаляться в зависимости от фильтров, а соответсвенно дополнительные Nested Loops и время на запрос доходит до секунды-полутора.

Есть идеи что сделать можно? Денормализовать слив в одну таблицу или ещё что-то сделать можно?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.07.2015, 06:26
    #39011846
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Sufir
Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT
	count(*)
FROM
	"th"."ticket" AS "self"
	 JOIN "th"."user_question" AS "question" ON question.id = self.id
WHERE
	self.status = 1 AND question.trash = FALSE



Explain:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
Aggregate  (cost=77913.98..77913.99 rows=1 width=0) (actual time=210.591..210.591 rows=1 loops=1)
  ->  Nested Loop  (cost=0.00..77861.94 rows=20816 width=0) (actual time=0.133..204.154 rows=21276 loops=1)
        ->  Index Scan using idx_th_ticket_status on ticket self  (cost=0.00..12774.44 rows=20816 width=4) (actual time=0.063..58.075 rows=21280 loops=1)
              Index Cond: (status = 1)
        ->  Index Scan using pk_th_user_question on user_question question  (cost=0.00..3.11 rows=1 width=4) (actual time=0.005..0.006 rows=1 loops=21280)
              Index Cond: (id = self.id)
              Filter: (NOT trash)
Total runtime: 240.652 ms



Четыре запроса - уже секунда, плюс десяток других, "лёгких" запросов, плюс отработка скрипта и уже полторы-две секунды на формирование страницы. Это очень много. Прегенерация не вариант, т.к. два десятка различных фильтров, на все комбинации не нагенеришь. Джойнов тоже может прибаляться в зависимости от фильтров, а соответсвенно дополнительные Nested Loops и время на запрос доходит до секунды-полутора.

Есть идеи что сделать можно? Денормализовать слив в одну таблицу или ещё что-то сделать можно?

Разобраться для чего вообще вы эти цифры показываете и отключить.
Так как в цифре есть 20816 открытых тикетов смысла ровно ноль для всех.
Еще может помочь создание индексов так чтобы наиболее популярные запросы шли через IOS (index only scan) это может ускорить раза в два-четыре.

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.07.2015, 20:20
    #39012720
Electric200
Electric200
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Лучше уже тригером обновлять счетчик в левой таблице при update/delete/insert на таблице с состояние тикетов. Чем делать этот "ацкий" count.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.07.2015, 20:50
    #39012728
p2.
p2.
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Electric200Лучше уже тригером обновлять счетчик в левой таблице при update/delete/insert на таблице с состояние тикетов. количество данных для "жутко тормозят" на линейной выборке по таблице многовероятно сформированы системой с многоболее одной транзакции одновременно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2015, 09:49
    #39013017
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
p2.,

да, реально чтений [страниц] там много меньше чем 21280 в лупах. хотелось бы buffers увидеть, чтобы значит скорость произвольного доступа оценить

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


если бы время было минуты, а числа -- миллионы -- можно бы было хенджобно параллелить по диапазонам ключей (через дблинк) -- за счет того, что 10 соединений получат больше %% дискового, чем одно -- при высокой конкуренции -- но работы там до пупа, а толку -- с гулькин чуть -- вот если бы ещё и вычислительный запрос -- тогда ядра бы параллелились
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2015, 09:59
    #39013037
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ускорение выполнения запроса SELECT COUNT
Sufir Прегенерация не вариант, т.к. два десятка различных фильтров, на все комбинации не нагенеришь.какбе прегененрировать можно не каунты а сабкаунтты -- 2 десятка -- это комбинация меньше 5! (факториал) -- т.е. вполне может оказаться кубик с <=5измерений, и одним ресурсом[count], который надо триггерно (точно) или асинхронно (оценочно) поддерживать. но не зная ваших фильтров -- не сообразить, так ли это.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / ускорение выполнения запроса SELECT COUNT / 16 сообщений из 16, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 344ms
Закрыть
start [/forum/topic.php?fid=53&mobile=1&tid=1997870]:
 0ms
get settings:
 8ms
get forum list:
 10ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 22ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 54ms
get tp. blocked users:
 1ms
others: 231ms
total:  344ms
x
x
Закрыть


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