|
влияние work_mem на план запроса - SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
при разных значениях work_mem PostgreSQL 9.6 для запроса вида Код: plsql 1.
строит разные планы при 4Мб (значение PG по умолчанию) -> Seq Scan on mytable при 8Мб ->Index Only Scan using "myid_pk" (используется первичный ключ) Фактические значения Код: plsql 1.
на серверах практически не различаются (несколько процентов всего). Планировщик оценивает возможность уместиться в отведенный work_mem и строит план или что-то ещё влияет на выбор? В остальных настройках и наборах данных серверы максимально идентичны. Какие приёмы позволят повысить эффективность (скорость) выполнения запросов подсчета количества строк? Отказаться от выполнения таких запросов не представляется возможным. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 08:33 |
|
влияние work_mem на план запроса - SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
pppsqlпри разных значениях work_mem PostgreSQL 9.6 для запроса вида Код: plsql 1.
строит разные планы при 4Мб (значение PG по умолчанию) -> Seq Scan on mytable при 8Мб ->Index Only Scan using "myid_pk" (используется первичный ключ) Фактические значения Код: plsql 1.
на серверах практически не различаются (несколько процентов всего). Планировщик оценивает возможность уместиться в отведенный work_mem и строит план или что-то ещё влияет на выбор? В остальных настройках и наборах данных серверы максимально идентичны. Какие приёмы позволят повысить эффективность (скорость) выполнения запросов подсчета количества строк? Отказаться от выполнения таких запросов не представляется возможным. 1)попробуйте там где база делает seq scan сделать vacuum analyze этой таблицы... может слишком много страницы без all visible bits стоит и база поэтому не хочет сделать Index only scan (впрочем учитывая что IOS на 9.6 в 1 поток делается - то это вряд ли самый быстрый метод для count(*) - см 2)) 2)так как у вас 9.6 скорее всего самый быстрый метод count(*) - включить параллельное выполнение запросов на 4-8-16 ядер (parralel seq scan). Как то так. PS: count(*) по 1 миллиард строк будет медленный как его не делайте :). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 10:28 |
|
влияние work_mem на план запроса - SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Maxim Boguk, vacuum analyze не влияет ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 12:02 |
|
влияние work_mem на план запроса - SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
pppsql, это вы на одном сервере work_mem меняете в сессии и получаете разные планы? покажите оба плана и вывод Код: sql 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2018, 17:13 |
|
влияние work_mem на план запроса - SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Alexius, физически серверы разные, но с одинаковой БД и настройками, кроме work_mem предлагаете протестировать на одном сервере с разными work_mem устанавливаемыми в сессии? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2018, 08:54 |
|
влияние work_mem на план запроса - SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
pppsqlAlexius, физически серверы разные, но с одинаковой БД и настройками, кроме work_mem предлагаете протестировать на одном сервере с разными work_mem устанавливаемыми в сессии? Для начала - да. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2018, 09:36 |
|
влияние work_mem на план запроса - SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
pppsql, я сомневаюсь, что в данном случае именно work_mem влияет на план. если получится на одном сервере воспроизвести будет очень интересно. сервера совсем разные получаются, это не мастер и реплика? на план в первую очередь по идее должны влиять параметры, которые я просил привести (с обоих серверов) + размер индекса, по которому index only scan. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2018, 09:41 |
|
|
start [/forum/topic.php?fid=53&fpage=57&tid=1995844]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
27ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 136ms |
0 / 0 |