ReSQL.ru
     
powered by simpleCommunicator - 2.0.40     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему date_trunc() в 1.5 раза медленнее?
22 сообщений из 22, страница 1 из 1
почему date_trunc() в 1.5 раза медленнее?
    #40067779
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
почему такой запрос:
Код: sql
1.
SELECT count(*) FROM logs WHERE ts >= date_trunc('quarter', CURRENT_DATE)


работает 5379 ms,
а такой запрос:
Код: sql
1.
SELECT count(*) FROM logs WHERE ts >= '2021-04-01 00:00:00'


работает 3649 ms
?
 
explain 1
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
                                                                  QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=174048.97..174048.98 rows=1 width=8) (actual time=5908.024..5918.314 rows=1 loops=1)
   ->  Gather  (cost=174048.75..174048.96 rows=2 width=8) (actual time=5906.178..5918.301 rows=3 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         ->  Partial Aggregate  (cost=173048.75..173048.76 rows=1 width=8) (actual time=5789.544..5789.545 rows=1 loops=3)
               ->  Parallel Seq Scan on logs  (cost=0.00..172865.73 rows=73208 width=0) (actual time=20.467..5754.649 rows=102398 loops=3)
                     Filter: (ts >= date_trunc('quarter'::text, (CURRENT_DATE)::timestamp with time zone))
                     Rows Removed by Filter: 1543742
 Planning Time: 0.289 ms
 JIT:
   Functions: 14
   Options: Inlining false, Optimization false, Expressions true, Deforming true
   Timing: Generation 5.180 ms, Inlining 0.000 ms, Optimization 1.541 ms, Emission 58.522 ms, Total 65.243 ms
 Execution Time: 5920.095 ms
(14 строк)


 
explain 2
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
                                                                  QUERY PLAN                                                                  
----------------------------------------------------------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=158616.32..158616.33 rows=1 width=8) (actual time=3635.491..3643.309 rows=1 loops=1)
   ->  Gather  (cost=158616.10..158616.31 rows=2 width=8) (actual time=3635.456..3643.280 rows=3 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         ->  Partial Aggregate  (cost=157616.10..157616.11 rows=1 width=8) (actual time=3514.064..3514.066 rows=1 loops=3)
               ->  Parallel Seq Scan on logs  (cost=0.00..157433.08 rows=73208 width=0) (actual time=17.067..3499.870 rows=102399 loops=3)
                     Filter: (ts >= '2021-04-01 00:00:00+03'::timestamp with time zone)
                     Rows Removed by Filter: 1543742
 Planning Time: 0.141 ms
 JIT:
   Functions: 14
   Options: Inlining false, Optimization false, Expressions true, Deforming true
   Timing: Generation 4.300 ms, Inlining 0.000 ms, Optimization 1.527 ms, Emission 48.801 ms, Total 54.629 ms
 Execution Time: 3644.699 ms
(14 строк)



кстати, индекс на ts есть, но почему-то "Parallel Seq Scan"...
...
Рейтинг: 0 / 0
01.05.2021, 16:38
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40067959
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
бабушкин зайчик,

я бы начал изучение вопрос с проверки следующих моментов:

1) выключил бы параллельное выполнение запросов и посмотрел бы на время выполнения запроса в 1 поток в обоих случаях
причем раза по 3-4 обе версии чтобы посмотреть действительно ли результаты воспроизводимо отличаются в 1.5 раза

если нет - то вопрос закрывается автоматически


если же даже без параллельного выполнения запросов есть 1.5 разницы стабильной в скорости работы - тогда будем думать.


2)про почему seq scan:

покажите что дает запрос
Код: sql
1.
explain analyze select * from logs;


и
Код: sql
1.
explain analyze SELECT * FROM logs WHERE ts >= '2021-04-01 00:00:00';


и тогда станет понятнее.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
02.05.2021, 19:27
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40067992
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
Код: sql
1.
2.
3.
4.
5.
6.
7.
explain analyze select * from logs;
                                                     QUERY PLAN                                                     
--------------------------------------------------------------------------------------------------------------------
 Seq Scan on logs  (cost=0.00..181264.22 rows=4943022 width=176) (actual time=0.063..3123.163 rows=4943179 loops=1)
 Planning Time: 0.148 ms
 Execution Time: 3403.351 ms
(3 rows)


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
explain analyze select * from logs where ts >= '2021-04-01 00:00:00';
                                                            QUERY PLAN                                                             
-----------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..176165.01 rows=175861 width=176) (actual time=2808.842..3907.344 rows=311952 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on logs  (cost=0.00..157578.91 rows=73275 width=176) (actual time=2693.320..3496.127 rows=103984 loops=3)
         Filter: (ts >= '2021-04-01 00:00:00+03'::timestamp with time zone)
         Rows Removed by Filter: 1543742
 Planning Time: 0.361 ms
 JIT:
   Functions: 6
   Options: Inlining false, Optimization false, Expressions true, Deforming true
   Timing: Generation 1.906 ms, Inlining 0.000 ms, Optimization 1.413 ms, Emission 41.299 ms, Total 44.618 ms
 Execution Time: 3934.283 ms
(12 rows)
...
Рейтинг: 0 / 0
02.05.2021, 22:59
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40067995
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
Maxim Boguk
1) выключил бы параллельное выполнение запросов

что именно и где надо выключить?
...
Рейтинг: 0 / 0
02.05.2021, 23:01
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068264
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
crutchmaster
Участник
бабушкин зайчик,

Потому что трунк мутит что-то с датой, а без него тупо сравнивается 2 лонга. На оракле такая же хрень у нас, трунк в запросы стараются не совать.
...
Рейтинг: 0 / 0
04.05.2021, 10:30
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068306
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
бабушкин зайчик
Maxim Boguk
1) выключил бы параллельное выполнение запросов

что именно и где надо выключить?


set max_parallel_workers_per_gather to 0;
explain (analyze, costs, buffers, timing) ваши запросы (лучше несколько раз выполнять).



Про seq scan - у вас больше 5% таблицы вычитывается в результат запроса... сильно не факт что index scan будет быстрее.


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
04.05.2021, 12:42
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068329
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
crutchmaster
бабушкин зайчик,

Потому что трунк мутит что-то с датой, а без него тупо сравнивается 2 лонга. На оракле такая же хрень у нас, трунк в запросы стараются не совать.

так он же 1 раз всего мутит...
Maxim Boguk
Про seq scan - у вас больше 5% таблицы вычитывается в результат запроса... сильно не факт что index scan будет быстрее.

разве там не 30% нужно, чтобы seq scan был?
...
Рейтинг: 0 / 0
04.05.2021, 13:58
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068394
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
бабушкин зайчик

Maxim Boguk
Про seq scan - у вас больше 5% таблицы вычитывается в результат запроса... сильно не факт что index scan будет быстрее.

разве там не 30% нужно, чтобы seq scan был?


Зависит от настроек базы и параметров оборудования...
на холодную на механических дисках даже 1% был/есть быстрее seq scan вычитывать.
30% почти всегда будет дешевле seq scan (и даже на 10%).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
04.05.2021, 17:48
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068406
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
crutchmaster
Участник
бабушкин зайчик
так он же 1 раз всего мутит.

Вот я тоже так думал, но походу всё сложнее.
...
Рейтинг: 0 / 0
04.05.2021, 19:05
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068562
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
crutchmaster
бабушкин зайчик
так он же 1 раз всего мутит.

Вот я тоже так думал, но походу всё сложнее.

Похоже, что выражение date_trunc('quarter', CURRENT_DATE) вычисляется не один раз, а для каждой строки запроса.

Начальный запрос:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= date_trunc('quarter', CURRENT_DATE);
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..20.00 rows=333 width=8) (actual time=1033.440..1556.926 rows=1756801 loops=1)
   Filter: (x >= date_trunc('quarter'::text, (CURRENT_DATE)::timestamp with time zone))
   Rows Removed by Filter: 2592000
 Planning Time: 0.062 ms
 Execution Time: 1603.852 ms


Если функцию CURRENT_DATE заменить на константу, то запрос ускоряется:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= date_trunc('quarter', '2021-05-05'::timestamptz);
                                                          QUERY PLAN                                                          
------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..15.00 rows=333 width=8) (actual time=792.809..1158.885 rows=1756801 loops=1)
   Filter: (x >= date_trunc('quarter'::text, '2021-05-05 00:00:00+03'::timestamp with time zone))
   Rows Removed by Filter: 2592000
 Planning Time: 0.046 ms
 Execution Time: 1205.695 ms


А если вызов date_trunc вложить в подзапрос, то ускоряется еще больше. Подзапрос в скобках (SELECT ..) на месте скалярного выражения, выполняется один раз на запрос (узел initplan):
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= (SELECT date_trunc('quarter', CURRENT_DATE));
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.02..12.52 rows=333 width=8) (actual time=469.365..624.000 rows=1756801 loops=1)
   Filter: (x >= $0)
   Rows Removed by Filter: 2592000
   InitPlan 1 (returns $0)
     ->  Result  (cost=0.00..0.02 rows=1 width=8) (actual time=0.006..0.006 rows=1 loops=1)
 Planning Time: 0.051 ms
 Execution Time: 671.918 ms


И это время практически не отличается, от времени выполнения с константой:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= '2021-04-01'::timestamptz;
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..12.50 rows=333 width=8) (actual time=464.859..610.222 rows=1756801 loops=1)
   Filter: (x >= '2021-04-01 00:00:00+03'::timestamp with time zone)
   Rows Removed by Filter: 2592000
 Planning Time: 0.043 ms
 Execution Time: 657.398 ms


Проверил на 12 и 13 версиях. Каждый запрос выполнял 4-5 раз, для получения стабильного времени выполнения.
...
Рейтинг: 0 / 0
05.05.2021, 13:45
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068575
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Павел Лузанов,

Ну хоть кто то не ленивый на этом форуме.
Спасибо большое.

Еще бы понять почему так, volatile функций я не смог найти в цепочке.
Жалко нельзя сделать set track_functions to 'system' для анализа какие системные функции вызывались в запросе и сколько.


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
05.05.2021, 14:23
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068626
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
А если с now() попробовать?

Код: 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.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
postgres=# EXPLAIN (ANALYZE) 
postgres-# SELECT * FROM generate_series(
postgres(#         '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
postgres(# ) AS g(x) WHERE g.x >= date_trunc('quarter', CURRENT_DATE);
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..20.00 rows=333 width=8) (actual time=1964.682..2968.155 rows=1756801 loops=1)
   Filter: (x >= date_trunc('quarter'::text, (CURRENT_DATE)::timestamp with time zone))
   Rows Removed by Filter: 2592000
 Planning Time: 0.081 ms
 Execution Time: 3055.582 ms
(5 rows)



postgres=# EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= date_trunc('quarter', CURRENT_DATE);
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..20.00 rows=333 width=8) (actual time=1959.069..2959.935 rows=1756801 loops=1)
   Filter: (x >= date_trunc('quarter'::text, (CURRENT_DATE)::timestamp with time zone))
   Rows Removed by Filter: 2592000
 Planning Time: 0.075 ms
 Execution Time: 3045.324 ms
(5 rows)



postgres=# EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= date_trunc('quarter', now());
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..17.50 rows=333 width=8) (actual time=1528.879..2209.693 rows=1756801 loops=1)
   Filter: (x >= date_trunc('quarter'::text, now()))
   Rows Removed by Filter: 2592000
 Planning Time: 0.066 ms
 Execution Time: 2292.239 ms
(5 rows)



postgres=# EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= date_trunc('quarter', now());
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..17.50 rows=333 width=8) (actual time=1516.669..2183.769 rows=1756801 loops=1)
   Filter: (x >= date_trunc('quarter'::text, now()))
   Rows Removed by Filter: 2592000
 Planning Time: 0.060 ms
 Execution Time: 2266.244 ms
(5 rows)



postgres=# EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= date_trunc('quarter', CURRENT_DATE);
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..20.00 rows=333 width=8) (actual time=1954.108..2957.411 rows=1756801 loops=1)
   Filter: (x >= date_trunc('quarter'::text, (CURRENT_DATE)::timestamp with time zone))
   Rows Removed by Filter: 2592000
 Planning Time: 0.062 ms
 Execution Time: 3044.910 ms
(5 rows)



postgres=# EXPLAIN (ANALYZE) 
SELECT * FROM generate_series(
        '2021-01-01'::timestamptz, '2021-06-01'::timestamptz, '3 s'::interval
) AS g(x) WHERE g.x >= date_trunc('quarter', now());
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series g  (cost=0.00..17.50 rows=333 width=8) (actual time=1513.830..2182.581 rows=1756801 loops=1)
   Filter: (x >= date_trunc('quarter'::text, now()))
   Rows Removed by Filter: 2592000
 Planning Time: 0.058 ms
 Execution Time: 2265.236 ms
(5 rows)



postgres=# select version();
                                                              version                                                               
------------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 11.11 (Debian 11.11-1.pgdg90+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit
(1 row)
...
Рейтинг: 0 / 0
05.05.2021, 16:02
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068639
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
CURRENT_DATE или now() - значение не имеет
а вот подзапрос имеет, даёт почти такой же результат, как константа
хотел бы я посмотреть на код этой замечательной функции...
...
Рейтинг: 0 / 0
05.05.2021, 17:00
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068641
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkij
Участник
бабушкин зайчик
хотел бы я посмотреть на код этой замечательной функции...

Могу научить:
берём в psql \sf date_trunc(text, timestamp)
затем ищем по исходникам git grep timestamp_trunc
находим https://github.com/postgres/postgres/blob/REL_13_STABLE/src/backend/utils/adt/timestamp.c#L3815
...
Рейтинг: 0 / 0
05.05.2021, 17:14
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068647
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
Maxim Boguk

Еще бы понять почему так, volatile функций я не смог найти в цепочке.

Разная скорость получается не только по сравнению date_trunc с константой, но и с другой stable функцией - now. Но что самое интересное, дело вовсе не в volatile. Любая из этих stable функций выполняется для каждой строки запроса. Просто now умеет кешировать свой результат, а date_trunc каждый раз выполняет разбор и усечение даты, на что время и уходит.

Рекомендация - использовать скалярные подзапросы (SELECT ..) или CTE.

Подробности здесь .
...
Рейтинг: 0 / 0
05.05.2021, 17:42
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40068653
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
Melkij
бабушкин зайчик
хотел бы я посмотреть на код этой замечательной функции...

Могу научить:
берём в psql \sf date_trunc(text, timestamp)
затем ищем по исходникам git grep timestamp_trunc
находим https://github.com/postgres/postgres/blob/REL_13_STABLE/src/backend/utils/adt/timestamp.c#L3815

очевидно копать придётся глубже
главный вопрос - кто додумался простую константу высчитывать для каждой строки
...
Рейтинг: 0 / 0
05.05.2021, 18:21
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40069281
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
Павел Лузанов
Подробности здесь .

Всё оказалось интереснее. Я для себя сделал следующие выводы.

Особенности выполнения любых(пользовательских, системных) STABLE функций в запросах вида:
Код: sql
1.
SELECT * FROM t WHERE col oper stable_func();


Отметка STABLE не гарантирует того, что функция будет выполнена только один раз. В случае последовательного сканирования таблицы, функция выполняется для каждой строки запроса.

Если в таблице есть индекс по столбцу col, то планировщик может выбрать сканирование индекса. В этом случае отметка STABLE дает право вычислить значение функции один раз и использовать это значение для поиска в индексе.

В случае последовательного сканирования, в стоимость плана помимо прочего входит стоимость функции умноженная на количество строк. Для пользовательских функций стоимость по умолчанию равна 100. Возможно это значение стоит изменить для более адекватной оценки. Уменьшение стоимости функции будет приводить к снижению стоимости последовательного сканирования таблицы и наоборот. Уточнение оценки стоимости функции даст возможность планировщику более точно сделать выбор между последовательным сканированием и сканированием индекса.

Если последовательное сканирование предпочтительнее, то избежать многократного выполнения функции можно при помощи материализации результата функции.

Есть два способа материализовать результат: скалярный подзапрос и CTE.
Код: sql
1.
SELECT * FROM t WHERE col oper (SELECT stable_func());


Код: sql
1.
WITH m AS MATERIALIZED (SELECT stable_func() AS f) SELECT * FROM t, m WHERE col oper m.f;


В любом случае у планировщика нет возможности использовать результат выполнения функции для построения плана. Поэтому не получится использовать статистику по столбцу t.col для выбора оптимального плана. При выборе плана будет использоваться общий алгоритм.
...
Рейтинг: 0 / 0
11.05.2021, 10:49
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40069291
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
crutchmaster
Участник
Павел Лузанов
Похоже, что выражение date_trunc('quarter', CURRENT_DATE) вычисляется не один раз, а для каждой строки запроса.

Это понятно, но какого хрена оно вычисляется каждый раз, если, вроде как, очевидно, что константное? Походу никто просто не стал греть себе голову тем, константное оно там или нет. ЕМПНИ в mysql такого не было, там в where можно было вводить переменные и всё срабатывало один раз.
...
Рейтинг: 0 / 0
11.05.2021, 11:28
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40069319
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
да постгря не первый раз удивляет
есть там неочевидное
...
Рейтинг: 0 / 0
11.05.2021, 12:50
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40069370
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
это ппц просто, надо снаружи БД (в PHP) пересчитать в константу, а её уже вставлять в запрос вместо date_trunc(), потому что SELECT date_trunc() тоже не спасает
и даже если в WITH date_trunc() засунуть, всё равно тормоза...
...и вот так тоже: CURRENT_DATE - '64 day'::interval
Только константа не тормозит.
...
Рейтинг: 0 / 0
11.05.2021, 15:32
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40069374
бабушкин зайчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
бабушкин зайчик
Гость
хм, а если '2021-04-01 00:00:00' увеличить до '2021-03-01', то опять те же тормоза...
...
Рейтинг: 0 / 0
11.05.2021, 15:45
| Ответить | Цитировать | Написать  
почему date_trunc() в 1.5 раза медленнее?
    #40069513
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
crutchmaster
Участник
бабушкин зайчик
это ппц просто

Не так быстро:) У меня наблюдались тормоза при передачи даты в оракл из ноды. А если передавать в to_date строку, работало в 2 раза быстрее.
...
Рейтинг: 0 / 0
12.05.2021, 04:41
| Ответить | Цитировать | Написать  
22 сообщений из 22, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / почему date_trunc() в 1.5 раза медленнее?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&fpage=12&tid=1994042]:
 0ms
get settings:
 11ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 27ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 56ms
get tp. blocked users:
 2ms
others: 279ms
total:  413ms
созд. / загр.: 413ms
x
x
Закрыть


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