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

Откуда: сетевой
Сообщений: 132
почему такой запрос:
SELECT count(*) FROM logs WHERE ts >= date_trunc('quarter', CURRENT_DATE)

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

работает 3649 ms
?
+ explain 1

                                                                  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

                                                                  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"...
1 май 21, 16:38    [22317258]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4720
бабушкин зайчик,

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

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

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


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


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

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

и
explain analyze SELECT * FROM logs WHERE ts >= '2021-04-01 00:00:00';

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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
2 май 21, 19:27    [22317585]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
бабушкин зайчик
Member

Откуда: сетевой
Сообщений: 132
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)

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)


Сообщение было отредактировано: 2 май 21, 22:56
2 май 21, 22:59    [22317651]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
бабушкин зайчик
Member

Откуда: сетевой
Сообщений: 132
Maxim Boguk
1) выключил бы параллельное выполнение запросов

что именно и где надо выключить?
2 май 21, 23:01    [22317654]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2317
бабушкин зайчик,

Потому что трунк мутит что-то с датой, а без него тупо сравнивается 2 лонга. На оракле такая же хрень у нас, трунк в запросы стараются не совать.
4 май 21, 10:30    [22318139]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4720
бабушкин зайчик
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
4 май 21, 12:42    [22318219]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
бабушкин зайчик
Member

Откуда: сетевой
Сообщений: 132
crutchmaster
бабушкин зайчик,

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

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

разве там не 30% нужно, чтобы seq scan был?
4 май 21, 13:58    [22318274]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4720
бабушкин зайчик

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

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


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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
4 май 21, 17:48    [22318424]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2317
бабушкин зайчик
так он же 1 раз всего мутит.

Вот я тоже так думал, но походу всё сложнее.
4 май 21, 19:05    [22318456]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Павел Лузанов
Member

Откуда:
Сообщений: 805
crutchmaster
бабушкин зайчик
так он же 1 раз всего мутит.

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

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

Начальный запрос:
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 заменить на константу, то запрос ускоряется:
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):
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

И это время практически не отличается, от времени выполнения с константой:
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 раз, для получения стабильного времени выполнения.
5 май 21, 13:45    [22318761]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4720
Павел Лузанов,

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

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


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
5 май 21, 14:23    [22318784]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Guzya
Member

Откуда:
Сообщений: 721
А если с now() попробовать?

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)


Сообщение было отредактировано: 5 май 21, 16:02
5 май 21, 16:02    [22318873]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
бабушкин зайчик
Member

Откуда: сетевой
Сообщений: 132
CURRENT_DATE или now() - значение не имеет
а вот подзапрос имеет, даёт почти такой же результат, как константа
хотел бы я посмотреть на код этой замечательной функции...

Сообщение было отредактировано: 5 май 21, 16:52
5 май 21, 17:00    [22318898]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 1290
бабушкин зайчик
хотел бы я посмотреть на код этой замечательной функции...

Могу научить:
берём в 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
5 май 21, 17:14    [22318904]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Павел Лузанов
Member

Откуда:
Сообщений: 805
Maxim Boguk

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

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

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

Подробности здесь.
5 май 21, 17:42    [22318924]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
бабушкин зайчик
Member

Откуда: сетевой
Сообщений: 132
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

очевидно копать придётся глубже
главный вопрос - кто додумался простую константу высчитывать для каждой строки
5 май 21, 18:21    [22318944]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
Павел Лузанов
Member

Откуда:
Сообщений: 805
Павел Лузанов
Подробности здесь.

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

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

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

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

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

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

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

WITH m AS MATERIALIZED (SELECT stable_func() AS f) SELECT * FROM t, m WHERE col oper m.f;

В любом случае у планировщика нет возможности использовать результат выполнения функции для построения плана. Поэтому не получится использовать статистику по столбцу t.col для выбора оптимального плана. При выборе плана будет использоваться общий алгоритм.
11 май 21, 10:49    [22320300]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2317
Павел Лузанов
Похоже, что выражение date_trunc('quarter', CURRENT_DATE) вычисляется не один раз, а для каждой строки запроса.

Это понятно, но какого хрена оно вычисляется каждый раз, если, вроде как, очевидно, что константное? Походу никто просто не стал греть себе голову тем, константное оно там или нет. ЕМПНИ в mysql такого не было, там в where можно было вводить переменные и всё срабатывало один раз.

Сообщение было отредактировано: 11 май 21, 11:20
11 май 21, 11:28    [22320329]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
бабушкин зайчик
Member

Откуда: сетевой
Сообщений: 132
да постгря не первый раз удивляет
есть там неочевидное
11 май 21, 12:50    [22320405]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
бабушкин зайчик
Member

Откуда: сетевой
Сообщений: 132
это ппц просто, надо снаружи БД (в PHP) пересчитать в константу, а её уже вставлять в запрос вместо date_trunc(), потому что SELECT date_trunc() тоже не спасает
и даже если в WITH date_trunc() засунуть, всё равно тормоза...
...и вот так тоже: CURRENT_DATE - '64 day'::interval
Только константа не тормозит.

Сообщение было отредактировано: 11 май 21, 15:31
11 май 21, 15:32    [22320506]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
бабушкин зайчик
Member

Откуда: сетевой
Сообщений: 132
хм, а если '2021-04-01 00:00:00' увеличить до '2021-03-01', то опять те же тормоза...
11 май 21, 15:45    [22320512]     Ответить | Цитировать Сообщить модератору
 Re: почему date_trunc() в 1.5 раза медленнее?  [new]
crutchmaster
Member

Откуда: оттуда.
Сообщений: 2317
бабушкин зайчик
это ппц просто

Не так быстро:) У меня наблюдались тормоза при передачи даты в оракл из ноды. А если передавать в to_date строку, работало в 2 раза быстрее.
12 май 21, 04:41    [22320735]     Ответить | Цитировать Сообщить модератору
Все форумы / PostgreSQL Ответить