Гость
Войти | Профиль | Очистить
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему так медленно? / 25 сообщений из 27, страница 1 из 2
  1  все
19.05.2019, 15:05
    #39815006
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
во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:58
    #39815025
Leonid Kudryavtsev
Leonid Kudryavtsev
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
Скрипты на создание таблиц и индексов.

Не спец в PostgreSQL, но при види слова "Bitmap" я сразу начинаю подозревает именно его.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.05.2019, 16:58
    #39815046
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудухво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, 19:23
    #39815094
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
Код: 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 не так плохо.
а мускулю это не мешает.

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

Не спец в PostgreSQL, но при види слова "Bitmap" я сразу начинаю подозревает именно его.
не понял, что сделать то надо?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.05.2019, 10:20
    #39815235
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудуха мускулю это не мешает.

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


подозреваю уид у вас лидирующее поле праймари кея, и в мускуле кластеризация по пк приводит к последовательному доступу, а не к произвольному. опять таки в мускуле вроде туча разных движков разной степени производительности и транзакционности.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.05.2019, 13:46
    #39815340
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудуха мускулю это не мешает.
Вопрос не в том что мускулю не мешает. Вопрос в том, что ему помогает. А помогает ему быстро выдать count(*) всей таблицы отсутствие условия фильтрации и транзакция dirty read.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.05.2019, 20:07
    #39815502
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудух
Код: 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:10
    #39815504
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
Dimitry Sibiryakovполудуха мускулю это не мешает.
Вопрос не в том что мускулю не мешает. Вопрос в том, что ему помогает. А помогает ему быстро выдать count(*) всей таблицы отсутствие условия фильтрации и транзакция dirty read.
есть ли статистика сравнения потери данных в мускуле и постгресе?
зачем он так усложнился, оно того стоило?
в мускуле может скорраптиться таблица, да, но её отремонтировать можно
в постгресе не может?

qwwqа кто вам мешает съе.хать взад на любимый вами мускуль ?
поздновато уже, когда FTS прикручен, массивы и прочая лабуда
запросы отличаются опять же
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.05.2019, 20:13
    #39815506
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
Maxim BogukА так да - хотите работать быстро и не выделяя много памяти под кеш - ставьте нормальный ssd... благо он не 20000 и даже не 1000 стоит.
Быстрее чем работает физический диск (а механика это 100-200IOPS в пределе) - база работать не будет... чудес не бывает.
таки постгрестники (ваш же Космодемьянский) постоянно намекают на контроллер с таблеткой
а он таки килобаксами меряется

Maxim BogukНу я бы начал с сравнения настроек по памяти mysql и postgresql (и по дискам). Если у вас postgresql вообще не настроен то там слезы а не ресурсы ему выделены (для кофеварки) и поэтому все запросы на диск попадают.
shared_buffers = 128MB
work_mem = 8MB
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.05.2019, 21:04
    #39815530
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудухMaxim BogukА так да - хотите работать быстро и не выделяя много памяти под кеш - ставьте нормальный ssd... благо он не 20000 и даже не 1000 стоит.
Быстрее чем работает физический диск (а механика это 100-200IOPS в пределе) - база работать не будет... чудес не бывает.
таки постгрестники (ваш же Космодемьянский) постоянно намекают на контроллер с таблеткой
а он таки килобаксами меряется


Если у вас механика - да без такого рейд контроллера вам никуда.
Если ssd то можно хоть mdraid софтовый (если диски нормальные) и по скорости будет в 1000-10000 быстрее чем механика.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.05.2019, 13:40
    #39815787
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудухесть ли статистика сравнения потери данных в мускуле и постгресе?
При чём тут потеря данных?

PG как и любой другой транзакционный SQL Server к твоему запросу добавляет условие "из записей видимых данной транзакцией", что и приводит к замедлению. Добавь это условие в MySQL и он точно так же затормозится.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.05.2019, 15:21
    #39815863
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
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:23
    #39815864
Leonid Kudryavtsev
Leonid Kudryavtsev
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудух...
нет там 1000
HDD READ ~ 120mb/s
SSD READ ~ 550 mb/s

таки есть:
HDD Average Seek Time - смотреть в описании конкретной модели
SSD Seek Time = 0
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
21.05.2019, 15:26
    #39815867
Maxim Boguk
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудух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:33
    #39815872
Leonid Kudryavtsev
Leonid Kudryavtsev
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
например 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:46
    #39815878
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
Maxim BogukПричем тут линейное чтение? Вы посмотрите сколько hdd на случайном чтении дает (а будет 100-200 iops или 1MB/s в лучшем случае).
База это не про линейное чтение ни в каком случае.
согласен

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

я таки не понял, мускуль DELETE делает без транзакций, а PG с транзакциями?
а count() ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.05.2019, 08:34
    #39816160
Lonepsycho
Lonepsycho
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудух,

какая версия постгреса? 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, 10:43
    #39816245
alex-ls
alex-ls
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудухпри том, что все эти заморочки (и транзакции там на 1м месте) придуманы именно для сохранности данных.
что это за наркоманский бред?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.05.2019, 14:42
    #39816530
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
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
| Ответить | Цитировать | Написать  
15.10.2019, 11:06
    #39876423
jan2ary
jan2ary
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудух,

Так и тестовый сценарий для обоих баз будет? Нетерпится проверить уже.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.10.2019, 16:10
    #39876642
fte
fte
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
полудух,
Может дурацкий вопрос, что ежели * заменить на id:
Код: sql
1.
explain (analyze, verbose, buffers) select count(id) from tasks_clients where owner_uid = 29;


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


Собственно, ИМНО по-любому накладные расходы...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.10.2019, 16:28
    #39876651
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
fte, тогда он ещё и id будет чекать на NOT NULL
а так ему пофигу
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.10.2019, 16:29
    #39876653
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
jan2ary, на любой таблице в 100к-1кк строк можно проверить
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.10.2019, 18:10
    #39876707
jan2ary
jan2ary
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
Так знать бы, куда смотреть.

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

А то мы сравниваем "mysql> explain select count(*) from tasks where uid=29;" и Using index в нем и удаление в постгресе.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.10.2019, 19:26
    #39876734
полудух
полудух
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
почему так медленно?
шта

Код: sql
1.
select count(id) from tasks_clients where owner_uid = 29;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему так медленно? / 25 сообщений из 27, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 159ms
Закрыть
start [/forum/topic.php?fid=53&tablet=1&tid=1995000]:
 0ms
get settings:
 7ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 45ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 64ms
get tp. blocked users:
 2ms
others: 14ms
total:  159ms
x
x
Закрыть


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