почему так медленно? / PostgreSQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему так медленно?

25 сообщений из 27, страница 1 из 2

все

почему так медленно?

#39815006

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

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

(тут следующий запрос - меньше строк = меньше время, но всё равно дохрена!)

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

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)

...

Рейтинг:

0 / 0

19.05.2019, 15:05

| Ответить | Цитировать | Написать

почему так медленно?

#39815025

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

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

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

...

Рейтинг:

0 / 0

19.05.2019, 15:58

| Ответить | Цитировать | Написать

почему так медленно?

#39815046

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

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

(тут следующий запрос - меньше строк = меньше время, но всё равно дохрена!)

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

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 не так плохо.

...

Рейтинг:

0 / 0

19.05.2019, 16:58

| Ответить | Цитировать | Написать

почему так медленно?

#39815094

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

                                                                 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 мс

...

Рейтинг:

0 / 0

19.05.2019, 19:23

| Ответить | Цитировать | Написать

почему так медленно?

#39815235

qwwq

Участник

Сообщения: 2 880

Рейтинг: 0 / 0

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

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

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

...

Рейтинг:

0 / 0

20.05.2019, 10:20

| Ответить | Цитировать | Написать

почему так медленно?

#39815340

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

20.05.2019, 13:46

| Ответить | Цитировать | Написать

почему так медленно?

#39815502

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

полудух

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

                                                                 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 в пределе) - база работать не будет... чудес не бывает.

...

Рейтинг:

0 / 0

20.05.2019, 20:07

| Ответить | Цитировать | Написать

почему так медленно?

#39815504

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

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

qwwqа кто вам мешает съе.хать взад на любимый вами мускуль ?
поздновато уже, когда FTS прикручен, массивы и прочая лабуда
запросы отличаются опять же

...

Рейтинг:

0 / 0

20.05.2019, 20:10

| Ответить | Цитировать | Написать

почему так медленно?

#39815506

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

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

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

...

Рейтинг:

0 / 0

20.05.2019, 20:13

| Ответить | Цитировать | Написать

почему так медленно?

#39815530

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

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

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

...

Рейтинг:

0 / 0

20.05.2019, 21:04

| Ответить | Цитировать | Написать

почему так медленно?

#39815787

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

полудухесть ли статистика сравнения потери данных в мускуле и постгресе?
При чём тут потеря данных?

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

...

Рейтинг:

0 / 0

21.05.2019, 13:40

| Ответить | Цитировать | Написать

почему так медленно?

#39815863

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

Dimitry Sibiryakovполудухесть ли статистика сравнения потери данных в мускуле и постгресе?
При чём тут потеря данных?

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

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

...

Рейтинг:

0 / 0

21.05.2019, 15:21

| Ответить | Цитировать | Написать

почему так медленно?

#39815864

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

полудух...
нет там 1000
HDD READ ~ 120mb/s
SSD READ ~ 550 mb/s

таки есть:
HDD Average Seek Time - смотреть в описании конкретной модели
SSD Seek Time = 0

...

Рейтинг:

0 / 0

21.05.2019, 15:23

| Ответить | Цитировать | Написать

почему так медленно?

#39815867

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

полудух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 и тогда вероятно ваш запрос будет быстрее кстати пока таблица не слишком большая.

...

Рейтинг:

0 / 0

21.05.2019, 15:26

| Ответить | Цитировать | Написать

почему так медленно?

#39815872

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

например 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 раз быстрее на чтение

...

Рейтинг:

0 / 0

21.05.2019, 15:33

| Ответить | Цитировать | Написать

почему так медленно?

#39815878

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

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

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

я таки не понял, мускуль DELETE делает без транзакций, а PG с транзакциями?
а count() ?

...

Рейтинг:

0 / 0

21.05.2019, 15:46

| Ответить | Цитировать | Написать

почему так медленно?

#39816160

Lonepsycho

Участник

Откуда: Siauliai, Литва

Сообщения: 593

Рейтинг: 0 / 0

полудух,

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

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

SELECT
  s.name, 
  s.setting,
  s.unit,
  s.context,
  s.source
FROM
  pg_settings AS s
WHERE
  s.source != 'default'

...

Рейтинг:

0 / 0

22.05.2019, 08:34

| Ответить | Цитировать | Написать

почему так медленно?

#39816245

alex-ls

Участник

Откуда: Иркутская обл - Пенза - Москва

Сообщения: 4 332

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

22.05.2019, 10:43

| Ответить | Цитировать | Написать

почему так медленно?

#39816530

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

Lonepsychoполудух,

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

DDL:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

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:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.

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)

Код: sql

1.
2.
3.
4.
5.
6.

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 |
+----+-------------+-------+------------+------+---------------------------------------+--------+---------+-------+------+----------+-------------+

за одно можете привести результат

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

SELECT
  s.name, 
  s.setting,
  s.unit,
  s.context,
  s.source
FROM
  pg_settings AS s
WHERE
  s.source != 'default'

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.

            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 строк)

...

Рейтинг:

0 / 0

22.05.2019, 14:42

| Ответить | Цитировать | Написать

почему так медленно?

#39876423

jan2ary

Участник

Откуда: Киев

Сообщения: 1 766

Рейтинг: 0 / 0

полудух,

Так и тестовый сценарий для обоих баз будет? Нетерпится проверить уже.

...

Рейтинг:

0 / 0

15.10.2019, 11:06

| Ответить | Цитировать | Написать

почему так медленно?

#39876642

fte

Участник

Откуда: Moscow

Сообщения: 402

Рейтинг: 0 / 0

полудух,
Может дурацкий вопрос, что ежели * заменить на id:

Код: sql

explain (analyze, verbose, buffers) select count(id) from tasks_clients where owner_uid = 29;

На count(*) в плане есть строка:

Код: sql

Output: id, owner_uid, peid, added, expire, txt, result, closed

Собственно, ИМНО по-любому накладные расходы...

...

Рейтинг:

0 / 0

15.10.2019, 16:10

| Ответить | Цитировать | Написать

почему так медленно?

#39876651

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

fte, тогда он ещё и id будет чекать на NOT NULL
а так ему пофигу

...

Рейтинг:

0 / 0

15.10.2019, 16:28

| Ответить | Цитировать | Написать

почему так медленно?

#39876653

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

jan2ary, на любой таблице в 100к-1кк строк можно проверить

...

Рейтинг:

0 / 0

15.10.2019, 16:29

| Ответить | Цитировать | Написать

почему так медленно?

#39876707

jan2ary

Участник

Откуда: Киев

Сообщения: 1 766

Рейтинг: 0 / 0

Так знать бы, куда смотреть.

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

А то мы сравниваем "mysql> explain select count(*) from tasks where uid=29;" и Using index в нем и удаление в постгресе.

...

Рейтинг:

0 / 0

15.10.2019, 18:10

| Ответить | Цитировать | Написать

почему так медленно?

#39876734

полудух

Участник

Откуда: планета орков, г.Зверополис

Сообщения: 1 099

Рейтинг: 0 / 0

шта

Код: sql

select count(id) from tasks_clients where owner_uid = 29;

...

Рейтинг:

0 / 0

15.10.2019, 19:26

| Ответить | Цитировать | Написать

25 сообщений из 27, страница 1 из 2

все

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему так медленно?

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?desktop=1&fid=53&tid=1995000]:	0ms
get settings:	11ms
get forum list:	16ms
check forum access:	4ms
check topic access:	4ms
track hit:	52ms
get topic data:	13ms
get forum data:	3ms
get page messages:	70ms
get tp. blocked users:	2ms
others:	273ms

total:	448ms