ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / ускорение выполнения запроса SELECT COUNT
16 сообщений из 16, страница 1 из 1
ускорение выполнения запроса SELECT COUNT
    #33864887
twistfire
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
twistfire
Участник
В веб-приложении (пхп) используются запросы вида
SELECT COUNT(*) FROM sometable;

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

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

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

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

Можно ли как-то увеличить скорость выполнения запроса, возможно нужно просто как-то изменить запрос на более уместный?Что за таблица? Сколько в ней записей? Индексы по таблице есть?
...
Рейтинг: 0 / 0
20.07.2006, 05:35
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #33865617
ChameLe0n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChameLe0n
Гость
Странно как-то искал.... Например:
/topic/216436&hl=count
/topic/251251&hl=count
/topic/227461&hl=count
...
Рейтинг: 0 / 0
20.07.2006, 06:58
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #33865621
ChameLe0n
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChameLe0n
Гость
авторЧто за таблица? Сколько в ней записей? Индексы по таблице есть?
Какое отношение к запросу с COUNT имеют индексы?
...
Рейтинг: 0 / 0
20.07.2006, 07:03
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #33865623
Владимор Конев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимор Конев
Участник
ChameLe0n авторЧто за таблица? Сколько в ней записей? Индексы по таблице есть?
Какое отношение к запросу с COUNT имеют индексы?Теперь уже никакого.
...
Рейтинг: 0 / 0
20.07.2006, 07:05
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #33866945
twistfire
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
twistfire
Участник
Все равно не понимаю.
Как у 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, 13:26
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #33867193
Фотография Кувалдин Роман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кувалдин Роман
Участник
Скорее всего у тебя очень много ID>0. Соответственно, веса планов для SEQ_SCAN и INDEX_SCAN одинаковые. Планировщику проще перелопатить таблицу, нежели перелопачивать индекс, и для каждого узла лезть в таблицу и доставать оттуда строку.
...
Рейтинг: 0 / 0
20.07.2006, 14:21
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #33869234
twistfire
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
twistfire
Участник
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
21.07.2006, 11:16
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
ускорение выполнения запроса SELECT COUNT
    #39011689
Sufir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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 и время на запрос доходит до секунды-полутора.

Есть идеи что сделать можно? Денормализовать слив в одну таблицу или ещё что-то сделать можно?
...
Рейтинг: 0 / 0
20.07.2015, 19:13
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #39011846
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
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, 06:26
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #39012720
Electric200
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Electric200
Участник
Лучше уже тригером обновлять счетчик в левой таблице при update/delete/insert на таблице с состояние тикетов. Чем делать этот "ацкий" count.
...
Рейтинг: 0 / 0
21.07.2015, 20:20
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #39012728
p2.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
p2.
Участник
Electric200Лучше уже тригером обновлять счетчик в левой таблице при update/delete/insert на таблице с состояние тикетов. количество данных для "жутко тормозят" на линейной выборке по таблице многовероятно сформированы системой с многоболее одной транзакции одновременно.
...
Рейтинг: 0 / 0
21.07.2015, 20:50
| Ответить | Цитировать | Написать  
ускорение выполнения запроса SELECT COUNT
    #39013017
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
qwwq
Участник
p2.,

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

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


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


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