Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
во1, count(*)
на таблице в 2 млн строк (всего-лишь)
занимает 20 сек
во2, DELETE
занимает 13 сек
(удаляет 143336 записей)
13 сек, карл
мускуль и count, и DEL делает за 0.5 сек (!!!)
запрос по единственному ключу - самый быстрый запрос в БД...
и походу этот факт уже никак не тюнится (

(тут следующий запрос - меньше строк = меньше время, но всё равно дохрена!)
explain analyze delete from logs where uid = 101;
                                                                 QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Delete on logs  (cost=1924.55..45283.98 rows=88274 width=6) (actual time=8929.737..8929.737 rows=0 loops=1)
   ->  Bitmap Heap Scan on logs  (cost=1924.55..45283.98 rows=88274 width=6) (actual time=1479.384..5416.791 rows=84488 loops=1)
         Recheck Cond: (uid = 101)
         Heap Blocks: exact=9448
         ->  Bitmap Index Scan on logs_uid_idx  (cost=0.00..1902.48 rows=88274 width=0) (actual time=1476.642..1476.642 rows=84496 loops=1)
               Index Cond: (uid = 101)
 Planning Time: 0.305 ms
 Execution Time: 8929.928 ms
(8 строк)

Время: 9230,510 мс (00:09,231)
19 май 19, 15:05    [21888197]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7994
Скрипты на создание таблиц и индексов.

Не спец в PostgreSQL, но при види слова "Bitmap" я сразу начинаю подозревает именно его.
19 май 19, 15:58    [21888229]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4030
полудух
во1, count(*)
на таблице в 2 млн строк (всего-лишь)
занимает 20 сек
во2, DELETE
занимает 13 сек
(удаляет 143336 записей)
13 сек, карл
мускуль и count, и DEL делает за 0.5 сек (!!!)
запрос по единственному ключу - самый быстрый запрос в БД...
и походу этот факт уже никак не тюнится (

(тут следующий запрос - меньше строк = меньше время, но всё равно дохрена!)
explain analyze delete from logs where uid = 101;
                                                                 QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Delete on logs  (cost=1924.55..45283.98 rows=88274 width=6) (actual time=8929.737..8929.737 rows=0 loops=1)
   ->  Bitmap Heap Scan on logs  (cost=1924.55..45283.98 rows=88274 width=6) (actual time=1479.384..5416.791 rows=84488 loops=1)
         Recheck Cond: (uid = 101)
         Heap Blocks: exact=9448
         ->  Bitmap Index Scan on logs_uid_idx  (cost=0.00..1902.48 rows=88274 width=0) (actual time=1476.642..1476.642 rows=84496 loops=1)
               Index Cond: (uid = 101)
 Planning Time: 0.305 ms
 Execution Time: 8929.928 ms
(8 строк)

Время: 9230,510 мс (00:09,231)


1)включаете track_io_timing в конфиге
2)делате explain (analyze, costs, buffers, timing) ваш запроса

Вероятнее всего у вас все время на работу с диском уходит (и диск у вас весьма неторопливый)...
в пределе 90.000 строк при случайном доступе с механического диска могут занять до 3х минут (100 iops * 180.000 операций обращения к диску)... так что 9s не так плохо.
19 май 19, 16:58    [21888259]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
                                                                 QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Delete on logs  (cost=1920.55..45279.98 rows=88274 width=6) (actual time=19465.707..19465.707 rows=0 loops=1)
   Buffers: shared hit=84537 read=9693 dirtied=9448 written=86
   I/O Timings: read=17112.324 write=3.701
   ->  Bitmap Heap Scan on logs  (cost=1920.55..45279.98 rows=88274 width=6) (actual time=1886.807..17510.057 rows=84488 loops=1)
         Recheck Cond: (uid = 101)
         Heap Blocks: exact=9448
         Buffers: shared hit=49 read=9693 dirtied=2763 written=86
         I/O Timings: read=17112.324 write=3.701
         ->  Bitmap Index Scan on logs_uid_idx  (cost=0.00..1898.48 rows=88274 width=0) (actual time=1836.689..1836.689 rows=84496 loops=1)
               Index Cond: (uid = 101)
               Buffers: shared read=294
               I/O Timings: read=1819.690
 Planning Time: 0.227 ms
 Execution Time: 19466.011 ms
(14 строк)

Время: 19658,221 мс (00:19,658)
Время: 0,557 мс

автор
read=17112.324

типа без ssd-raid-контроллера за $20000 работать не буду?
Maxim Boguk
Вероятнее всего у вас все время на работу с диском уходит (и диск у вас весьма неторопливый)...
в пределе 90.000 строк при случайном доступе с механического диска могут занять до 3х минут (100 iops * 180.000 операций обращения к диску)... так что 9s не так плохо.

а мускулю это не мешает.

Leonid Kudryavtsev
Скрипты на создание таблиц и индексов.

Не спец в PostgreSQL, но при види слова "Bitmap" я сразу начинаю подозревает именно его.

не понял, что сделать то надо?
19 май 19, 19:23    [21888334]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
qwwq
Member

Откуда:
Сообщений: 2852
полудух
а мускулю это не мешает.

а кто вам мешает съе.хать взад на любимый вами мускуль ?


подозреваю уид у вас лидирующее поле праймари кея, и в мускуле кластеризация по пк приводит к последовательному доступу, а не к произвольному. опять таки в мускуле вроде туча разных движков разной степени производительности и транзакционности.
20 май 19, 10:20    [21888601]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48628
полудух
а мускулю это не мешает.

Вопрос не в том что мускулю не мешает. Вопрос в том, что ему помогает. А помогает ему быстро выдать count(*) всей таблицы отсутствие условия фильтрации и транзакция dirty read.
20 май 19, 13:46    [21888860]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4030
полудух
                                                                 QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------
 Delete on logs  (cost=1920.55..45279.98 rows=88274 width=6) (actual time=19465.707..19465.707 rows=0 loops=1)
   Buffers: shared hit=84537 read=9693 dirtied=9448 written=86
   I/O Timings: read=17112.324 write=3.701
   ->  Bitmap Heap Scan on logs  (cost=1920.55..45279.98 rows=88274 width=6) (actual time=1886.807..17510.057 rows=84488 loops=1)
         Recheck Cond: (uid = 101)
         Heap Blocks: exact=9448
         Buffers: shared hit=49 read=9693 dirtied=2763 written=86
         I/O Timings: read=17112.324 write=3.701
         ->  Bitmap Index Scan on logs_uid_idx  (cost=0.00..1898.48 rows=88274 width=0) (actual time=1836.689..1836.689 rows=84496 loops=1)
               Index Cond: (uid = 101)
               Buffers: shared read=294
               I/O Timings: read=1819.690
 Planning Time: 0.227 ms
 Execution Time: 19466.011 ms
(14 строк)

Время: 19658,221 мс (00:19,658)
Время: 0,557 мс

автор
read=17112.324

типа без ssd-raid-контроллера за $20000 работать не буду?
Maxim Boguk
Вероятнее всего у вас все время на работу с диском уходит (и диск у вас весьма неторопливый)...
в пределе 90.000 строк при случайном доступе с механического диска могут занять до 3х минут (100 iops * 180.000 операций обращения к диску)... так что 9s не так плохо.

а мускулю это не мешает.


Ну я бы начал с сравнения настроек по памяти mysql и postgresql (и по дискам). Если у вас postgresql вообще не настроен то там слезы а не ресурсы ему выделены (для кофеварки) и поэтому все запросы на диск попадают.

Еще полезно было бы сделать cluster logs using logs_uid_idx; (операция блокирующая)
если вам надо быстро удалять (но поможет разово пока таблица остаентся упорядочена).

А так да - хотите работать быстро и не выделяя много памяти под кеш - ставьте нормальный ssd... благо он не 20000 и даже не 1000 стоит.
Быстрее чем работает физический диск (а механика это 100-200IOPS в пределе) - база работать не будет... чудес не бывает.
20 май 19, 20:07    [21889188]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
Dimitry Sibiryakov
полудух
а мускулю это не мешает.

Вопрос не в том что мускулю не мешает. Вопрос в том, что ему помогает. А помогает ему быстро выдать count(*) всей таблицы отсутствие условия фильтрации и транзакция dirty read.

есть ли статистика сравнения потери данных в мускуле и постгресе?
зачем он так усложнился, оно того стоило?
в мускуле может скорраптиться таблица, да, но её отремонтировать можно
в постгресе не может?

qwwq
а кто вам мешает съе.хать взад на любимый вами мускуль ?

поздновато уже, когда FTS прикручен, массивы и прочая лабуда
запросы отличаются опять же
20 май 19, 20:10    [21889192]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
Maxim Boguk
А так да - хотите работать быстро и не выделяя много памяти под кеш - ставьте нормальный ssd... благо он не 20000 и даже не 1000 стоит.
Быстрее чем работает физический диск (а механика это 100-200IOPS в пределе) - база работать не будет... чудес не бывает.

таки постгрестники (ваш же Космодемьянский) постоянно намекают на контроллер с таблеткой
а он таки килобаксами меряется

Maxim Boguk
Ну я бы начал с сравнения настроек по памяти mysql и postgresql (и по дискам). Если у вас postgresql вообще не настроен то там слезы а не ресурсы ему выделены (для кофеварки) и поэтому все запросы на диск попадают.

shared_buffers = 128MB
work_mem = 8MB
20 май 19, 20:13    [21889195]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4030
полудух
Maxim Boguk
А так да - хотите работать быстро и не выделяя много памяти под кеш - ставьте нормальный ssd... благо он не 20000 и даже не 1000 стоит.
Быстрее чем работает физический диск (а механика это 100-200IOPS в пределе) - база работать не будет... чудес не бывает.

таки постгрестники (ваш же Космодемьянский) постоянно намекают на контроллер с таблеткой
а он таки килобаксами меряется


Если у вас механика - да без такого рейд контроллера вам никуда.
Если ssd то можно хоть mdraid софтовый (если диски нормальные) и по скорости будет в 1000-10000 быстрее чем механика.
20 май 19, 21:04    [21889224]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48628
полудух
есть ли статистика сравнения потери данных в мускуле и постгресе?

При чём тут потеря данных?

PG как и любой другой транзакционный SQL Server к твоему запросу добавляет условие "из записей видимых данной транзакцией", что и приводит к замедлению. Добавь это условие в MySQL и он точно так же затормозится.
21 май 19, 13:40    [21889700]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
Dimitry Sibiryakov
полудух
есть ли статистика сравнения потери данных в мускуле и постгресе?

При чём тут потеря данных?

PG как и любой другой транзакционный SQL Server к твоему запросу добавляет условие "из записей видимых данной транзакцией", что и приводит к замедлению. Добавь это условие в MySQL и он точно так же затормозится.

при том, что все эти заморочки (и транзакции там на 1м месте) придуманы именно для сохранности данных.

Maxim Boguk
Если у вас механика - да без такого рейд контроллера вам никуда.
Если ssd то можно хоть mdraid софтовый (если диски нормальные) и по скорости будет в 1000-10000 быстрее чем механика.

нет там 1000
HDD READ ~ 120mb/s
SSD READ ~ 550 mb/s
21 май 19, 15:21    [21889812]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7994
полудух
...
нет там 1000
HDD READ ~ 120mb/s
SSD READ ~ 550 mb/s


таки есть:
HDD Average Seek Time - смотреть в описании конкретной модели
SSD Seek Time = 0
21 май 19, 15:23    [21889813]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4030
полудух
Dimitry Sibiryakov
пропущено...

При чём тут потеря данных?

PG как и любой другой транзакционный SQL Server к твоему запросу добавляет условие "из записей видимых данной транзакцией", что и приводит к замедлению. Добавь это условие в MySQL и он точно так же затормозится.

при том, что все эти заморочки (и транзакции там на 1м месте) придуманы именно для сохранности данных.

Maxim Boguk
Если у вас механика - да без такого рейд контроллера вам никуда.
Если ssd то можно хоть mdraid софтовый (если диски нормальные) и по скорости будет в 1000-10000 быстрее чем механика.

нет там 1000
HDD READ ~ 120mb/s
SSD READ ~ 550 mb/s


Причем тут линейное чтение? Вы посмотрите сколько hdd на случайном чтении дает (а будет 100-200 iops или 1MB/s в лучшем случае).
База это не про линейное чтение ни в каком случае.

PS: если у вас такой тормозной диск то сколько у вас стоит random_page_cost / seq_page_cost в конфиге? Я бы поставил 20 / 1 и тогда вероятно ваш запрос будет быстрее кстати пока таблица не слишком большая.
21 май 19, 15:26    [21889819]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7994
например Seagate Barracuda
https://www.seagate.com/staticfiles/support/disc/manuals/desktop/Barracuda 7200.11/100507013c.pdf

Average latency 4.16 msec
Track-to-track seek time <0.8 msec typical read;
<1.0 msec typical write
Average seek, read <8.5 msec typical
Average seek, write <10.0 msec typical

8.5 msec = 1000 / 8.5 = 117 случайных IOPS

SSD Sumsung Evo PRO 850 (такой лежит сейчас передо мной)
https://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850pro/

RANDOM READ (4KB, QD32) Up to 100,000 IOPS
RANDOM READ (4KB, QD1) Up to 10,000 IOPS

по IOPS'ам и спецификации получается от 40 до 850 раз быстрее на чтение
21 май 19, 15:33    [21889825]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
Maxim Boguk
Причем тут линейное чтение? Вы посмотрите сколько hdd на случайном чтении дает (а будет 100-200 iops или 1MB/s в лучшем случае).
База это не про линейное чтение ни в каком случае.

согласен

PS: если у вас такой тормозной диск то сколько у вас стоит random_page_cost / seq_page_cost в конфиге? Я бы поставил 20 / 1 и тогда вероятно ваш запрос будет быстрее кстати пока таблица не слишком большая.

не заметно пока...
ясно, что на SSD поедет быстрее
не ясно - на сколько )
но я попробую, спасибо

я таки не понял, мускуль DELETE делает без транзакций, а PG с транзакциями?
а count() ? Картинка с другого сайта.
21 май 19, 15:46    [21889836]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
Lonepsycho
Member

Откуда: Siauliai, Литва
Сообщений: 554
полудух,

какая версия постгреса? DDL таблицы, и EXPLAIN (лучше EXPLAIN (ANALYZE, VERBOSE, BUFFERS)) в студию. для сравнения можете привести и EXPLAIN SELECT count(*) FROM... из мускуля. тогда можно смотреть что и почему. за одно можете привести результат
SELECT
  s.name, 
  s.setting,
  s.unit,
  s.context,
  s.source
FROM
  pg_settings AS s
WHERE
  s.source != 'default'
22 май 19, 08:34    [21890246]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6744
полудух
при том, что все эти заморочки (и транзакции там на 1м месте) придуманы именно для сохранности данных.

что это за наркоманский бред?
22 май 19, 10:43    [21890380]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
Lonepsycho
полудух,

какая версия постгреса? DDL таблицы, и EXPLAIN (лучше EXPLAIN (ANALYZE, VERBOSE, BUFFERS)) в студию. для сравнения можете привести и EXPLAIN SELECT count(*) FROM... из мускуля. тогда можно смотреть что и почему.

psql (11.3 (Debian 11.3-1.pgdg80+1))

DDL:
CREATE TABLE tasks_clients(
id serial
,owner_uid int NOT NULL
,peid int NOT NULL
,added timestamptz(0) NOT NULL default NOW()
,expire timestamptz(0) NOT NULL
,txt text NOT NULL
,result text
,closed timestamptz(0)
);

ALTER TABLE tasks_clients ADD PRIMARY KEY (id);
CREATE INDEX ON tasks_clients (owner_uid);
CREATE INDEX ON tasks_clients (peid);
CREATE INDEX ON tasks_clients (closed);
CREATE INDEX ON tasks_clients (expire);

ALTER TABLE tasks_clients ADD FOREIGN KEY (owner_uid) REFERENCES users(id) ON DELETE CASCADE;
ALTER TABLE tasks_clients ADD FOREIGN KEY (peid) REFERENCES clients(id) ON DELETE CASCADE;

EXPLAIN:
+
explain (analyze, verbose, buffers) select count(*) from tasks_clients where owner_uid = 29;
                                                                       QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=12268.48..12268.49 rows=1 width=8) (actual time=1480.237..1480.237 rows=1 loops=1)
   Output: count(*)
   Buffers: shared hit=6791 read=1878 dirtied=37 written=2
   I/O Timings: read=3966.386 write=0.178
   ->  Gather  (cost=12268.26..12268.47 rows=2 width=8) (actual time=1475.465..1851.525 rows=3 loops=1)
         Output: (PARTIAL count(*))
         Workers Planned: 2
         Workers Launched: 2
         Buffers: shared hit=6791 read=1878 dirtied=37 written=2
         I/O Timings: read=3966.386 write=0.178
         ->  Partial Aggregate  (cost=11268.26..11268.27 rows=1 width=8) (actual time=1387.563..1387.564 rows=1 loops=3)
               Output: PARTIAL count(*)
               Buffers: shared hit=6791 read=1878 dirtied=37 written=2
               I/O Timings: read=3966.386 write=0.178
               Worker 0: actual time=1346.500..1346.501 rows=1 loops=1
                 Buffers: shared hit=2451 read=498 dirtied=11 written=2
                 I/O Timings: read=1272.087 write=0.178
               Worker 1: actual time=1343.785..1343.785 rows=1 loops=1
                 Buffers: shared hit=2042 read=528 dirtied=10
                 I/O Timings: read=1287.925
               ->  Parallel Seq Scan on tasks_clients  (cost=0.00..11259.47 rows=3516 width=0) (actual time=14.945..1387.172 rows=2798 loops=3)
                     Output: id, owner_uid, peid, added, expire, txt, result, closed
                     Filter: (tasks_clients.owner_uid = 29)
                     Rows Removed by Filter: 162879
                     Buffers: shared hit=6791 read=1878 dirtied=37 written=2
                     I/O Timings: read=3966.386 write=0.178
                     Worker 0: actual time=0.086..1346.107 rows=2765 loops=1
                       Buffers: shared hit=2451 read=498 dirtied=11 written=2
                       I/O Timings: read=1272.087 write=0.178
                     Worker 1: actual time=2.457..1343.514 rows=1799 loops=1
                       Buffers: shared hit=2042 read=528 dirtied=10
                       I/O Timings: read=1287.925
 Planning Time: 0.550 ms
 Execution Time: 1851.877 ms
(34 строки)

Время: 1854,640 мс (00:01,855)


mysql> explain select count(*) from tasks where uid=29;
+----+-------------+-------+------------+------+---------------------------------------+--------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys                         | key    | key_len | ref   | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------------------------------+--------+---------+-------+------+----------+-------------+
|  1 | SIMPLE      | tasks  | NULL       | ref  | user_expire,uid,user_expire_closed | uid | 2       | const | 4662 |   100.00 | Using index |
+----+-------------+-------+------------+------+---------------------------------------+--------+---------+-------+------+----------+-------------+

за одно можете привести результат
SELECT
  s.name, 
  s.setting,
  s.unit,
  s.context,
  s.source
FROM
  pg_settings AS s
WHERE
  s.source != 'default'

+
            name            |                 setting                 | unit |  context   |        source                                                                                       
----------------------------+-----------------------------------------+------+------------+----------------------                                                                               
 application_name           | psql                                    | &#9830;&#9830;&#9830;  | user       | client                                                                                              
 authentication_timeout     | 5                                       | s    | sighup     | configuration file                                                                                  
 client_encoding            | UTF8                                    | &#9830;&#9830;&#9830;  | user       | client                                                                                              
 cluster_name               | 11/main                                 | &#9830;&#9830;&#9830;  | postmaster | configuration file
 config_file                | /etc/postgresql/11/main/postgresql.conf | &#9830;&#9830;&#9830;  | postmaster | override
 data_checksums             | off                                     | &#9830;&#9830;&#9830;  | internal   | override
 data_directory             | /var/lib/postgresql/11/main             | &#9830;&#9830;&#9830;  | postmaster | override
 DateStyle                  | ISO, DMY                                | &#9830;&#9830;&#9830;  | user       | configuration file
 default_text_search_config | pg_catalog.russian                      | &#9830;&#9830;&#9830;  | user       | configuration file
 dynamic_shared_memory_type | posix                                   | &#9830;&#9830;&#9830;  | postmaster | configuration file
 effective_cache_size       | 81920                                   | 8kB  | user       | configuration file
 external_pid_file          | /var/run/postgresql/11-main.pid         | &#9830;&#9830;&#9830;  | postmaster | configuration file
 hba_file                   | /etc/postgresql/11/main/pg_hba.conf     | &#9830;&#9830;&#9830;  | postmaster | override
 ident_file                 | /etc/postgresql/11/main/pg_ident.conf   | &#9830;&#9830;&#9830;  | postmaster | override
 lc_collate                 | ru_RU.UTF-8                             | &#9830;&#9830;&#9830;  | internal   | override
 lc_ctype                   | ru_RU.UTF-8                             | &#9830;&#9830;&#9830;  | internal   | override
 lc_messages                | ru_RU.UTF-8                             | &#9830;&#9830;&#9830;  | superuser  | configuration file
 lc_monetary                | ru_RU.UTF-8                             | &#9830;&#9830;&#9830;  | user       | configuration file
 lc_numeric                 | ru_RU.UTF-8                             | &#9830;&#9830;&#9830;  | user       | configuration file
 lc_time                    | ru_RU.UTF-8                             | &#9830;&#9830;&#9830;  | user       | configuration file
 listen_addresses           |                                         | &#9830;&#9830;&#9830;  | postmaster | configuration file
 log_line_prefix            | %m [%p] %q%u@%d                         | &#9830;&#9830;&#9830;  | sighup     | configuration file
 log_timezone               | W-SU                                    | &#9830;&#9830;&#9830;  | sighup     | configuration file
 max_connections            | 100                                     | &#9830;&#9830;&#9830;  | postmaster | configuration file
 max_prepared_transactions  | 0                                       | &#9830;&#9830;&#9830;  | postmaster | configuration file
 max_stack_depth            | 2048                                    | kB   | superuser  | environment variable
 port                       | 5432                                    | &#9830;&#9830;&#9830;  | postmaster | configuration file
 random_page_cost           | 20                                      | &#9830;&#9830;&#9830;  | user       | configuration file
 search_path                | klinovik                            | &#9830;&#9830;&#9830;  | user       | database
 server_encoding            | UTF8                                    | &#9830;&#9830;&#9830;  | internal   | override
 shared_buffers             | 16384                                   | 8kB  | postmaster | configuration file
 shared_preload_libraries   | pg_stat_statements                      | &#9830;&#9830;&#9830;  | postmaster | configuration file
 ssl                        | on                                      | &#9830;&#9830;&#9830;  | sighup     | configuration file
 ssl_cert_file              | /etc/ssl/certs/ssl-cert-snakeoil.pem    | &#9830;&#9830;&#9830;  | sighup     | configuration file
 ssl_key_file               | /etc/ssl/private/ssl-cert-snakeoil.key  | &#9830;&#9830;&#9830;  | sighup     | configuration file
 stats_temp_directory       | /var/run/postgresql/11-main.pg_stat_tmp | &#9830;&#9830;&#9830;  | sighup     | configuration file
 synchronous_commit         | on                                      | &#9830;&#9830;&#9830;  | user       | configuration file
 TimeZone                   | W-SU                                    | &#9830;&#9830;&#9830;  | user       | configuration file
 track_io_timing            | on                                      | &#9830;&#9830;&#9830;  | superuser  | configuration file
 transaction_deferrable     | off                                     | &#9830;&#9830;&#9830;  | user       | override
 transaction_isolation      | read committed                          | &#9830;&#9830;&#9830;  | user       | override
 transaction_read_only      | off                                     | &#9830;&#9830;&#9830;  | user       | override
 unix_socket_directories    | /var/run/postgresql                     | &#9830;&#9830;&#9830;  | postmaster | configuration file
 wal_buffers                | 512                                     | 8kB  | postmaster | override
 wal_level                  | replica                                 | &#9830;&#9830;&#9830;  | postmaster | configuration file
 wal_segment_size           | 16777216                                | B    | internal   | override
 work_mem                   | 8192                                    | kB   | user       | configuration file
(47 строк)
22 май 19, 14:42    [21890817]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
jan2ary
Member

Откуда: Киев
Сообщений: 1777
полудух,

Так и тестовый сценарий для обоих баз будет? Нетерпится проверить уже.
15 окт 19, 11:06    [21994385]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
fte
Member

Откуда: Moscow
Сообщений: 350
полудух,
Может дурацкий вопрос, что ежели * заменить на id:
explain (analyze, verbose, buffers) select count(id) from tasks_clients where owner_uid = 29;

На count(*) в плане есть строка:
Output: id, owner_uid, peid, added, expire, txt, result, closed

Собственно, ИМНО по-любому накладные расходы...
15 окт 19, 16:10    [21994770]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
fte, тогда он ещё и id будет чекать на NOT NULL
а так ему пофигу
15 окт 19, 16:28    [21994795]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
jan2ary, на любой таблице в 100к-1кк строк можно проверить
15 окт 19, 16:29    [21994797]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
jan2ary
Member

Откуда: Киев
Сообщений: 1777
Так знать бы, куда смотреть.

Потому что фраза "запрос по единственному ключу - самый быстрый запрос в БД..." сразу вызывает вопросы к постановке эксперимента.

А то мы сравниваем "mysql> explain select count(*) from tasks where uid=29;" и Using index в нем и удаление в постгресе.
15 окт 19, 18:10    [21994875]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
шта Картинка с другого сайта.
select count(id) from tasks_clients where owner_uid = 29;
15 окт 19, 19:26    [21994922]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
jan2ary
Member

Откуда: Киев
Сообщений: 1777
полудух,

postgres=# \timing 
Timing is on.
postgres=# CREATE TABLE sensor_log (
postgres(#   id            SERIAL NOT NULL PRIMARY KEY,
postgres(#   location      VARCHAR NOT NULL,
postgres(#   reading       BIGINT NOT NULL,
postgres(#   reading_date  TIMESTAMP NOT NULL
postgres(# );
CREATE TABLE
Time: 100.977 ms
postgres=# INSERT INTO sensor_log (id, location, reading, reading_date)
postgres-# SELECT s.id, s.id % 1000, s.id % 100,
postgres-#        CURRENT_DATE - ((s.id * 10) || 's')::INTERVAL
postgres-#   FROM generate_series(1, 1000000) s(id);
INSERT 0 1000000
Time: 10052.855 ms (00:10.053)
postgres=# select count(*) from sensor_log;
  count  
---------
 1000000
(1 row)

Time: 46.298 ms

postgres=# select count(*) from sensor_log where location::int % 20 = 0;
 count 
-------
 50000
(1 row)

Time: 85.917 ms

postgres=# delete from sensor_log where location::int % 23 = 0;
DELETE 44000
Time: 1137.541 ms (00:01.138)
postgres=# 
postgres=# select count(*) from sensor_log;
 count  
--------
 956000
(1 row)

Time: 55.527 ms
15 окт 19, 19:42    [21994940]     Ответить | Цитировать Сообщить модератору
 Re: почему так медленно?  [new]
полудух
Member

Откуда: планета орков, г.Зверополис
Сообщений: 938
да это у меня тоже быстро работает
на той таблице висит FK:
Foreign-key constraints:
    "logs_uid_fkey" FOREIGN KEY (uid) REFERENCES users(id) ON DELETE CASCADE

вот он тормозит юзеров отовсюду вытирать
в users много FK
а вот count() ещё надо поисследовать
15 окт 19, 20:58    [21994973]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / PostgreSQL Ответить