Оптимизировать запрос к большой таблице, выполняя generate_series () - PullRequest
Новая
       33

Оптимизировать запрос к большой таблице, выполняя generate_series ()

0 голосов
/ 17 января 2019

Следующий запрос занимает больше 7 минут в PostgreSQL 11.1: 

SELECT 
    '2019-01-19' as date, 
    '2019-01-19'::date - generate_series(first_observed, last_observed, interval '1 day')::date as days_to_date, 
    ROUND(AVG(price)) as price,
    area_id
FROM 
    table_example
GROUP BY 
    days_to_date, area_id;

table_example имеет около 15 миллионов строк .
Есть ли способы его оптимизировать? Я уже добавил следующие индексы: 

CREATE INDEX ON table_example (first_observed, last_observed);
CREATE INDEX ON table_example (area_id);

Это вывод из EXPLAIN (ANALYZE,BUFFERS): 

GroupAggregate  (cost=3235559683.68..3377398628.68 rows=1418000 width=72) (actual time=334933.966..440096.869 rows=21688 loops=1)
  Group Key: (('2019-01-19'::date - ((generate_series((first_observed)::timestamp with time zone, (last_observed)::timestamp with time zone, '1 day'::interval)))::date)), area_id
  Buffers: local read=118167 dirtied=118167 written=117143, temp read=1634631 written=1635058
  ->  Sort  (cost=3235559683.68..3271009671.18 rows=14179995000 width=40) (actual time=334923.933..391690.184 rows=380203171 loops=1)
        Sort Key: (('2019-01-19'::date - ((generate_series((first_observed)::timestamp with time zone, (last_observed)::timestamp with time zone, '1 day'::interval)))::date)), area_id
        Sort Method: external merge  Disk: 9187584kB
        Buffers: local read=118167 dirtied=118167 written=117143, temp read=1634631 written=1635058
        ->  Result  (cost=0.00..390387079.39 rows=14179995000 width=40) (actual time=214.798..171717.941 rows=380203171 loops=1)
              Buffers: local read=118167 dirtied=118167 written=117143
              ->  ProjectSet  (cost=0.00..71337191.89 rows=14179995000 width=44) (actual time=214.796..102823.749 rows=380203171 loops=1)
                    Buffers: local read=118167 dirtied=118167 written=117143
                    ->  Seq Scan on table_example  (cost=0.00..259966.95 rows=14179995 width=44) (actual time=0.031..2449.511 rows=14179995 loops=1)
                          Buffers: local read=118167 dirtied=118167 written=117143
Planning Time: 0.409 ms
JIT:
  Functions: 18
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 5.034 ms, Inlining 13.010 ms, Optimization 121.440 ms, Emission 79.996 ms, Total 219.480 ms
Execution Time: 441133.410 ms

Вот как выглядит table_example: 

column name        data type
'house_pk'         'integer'    
'date_in'          'date'   
'first_observed'   'date'   
'last_observed'    'date'   
'price'            'numeric'    
'area_id'          'integer'

Есть 60 различных area_ids.

Запрос выполняется на многоядерном компьютере (24 ядра) со 128 ГБ памяти. Однако возможно, что настройки не являются оптимальными.

1 Ответ

0 голосов
/ 18 января 2019

При обработке всей таблицы индексы, как правило, бесполезны (с возможным исключением сканирования только по индексу, если строки таблицы намного шире индекса).

И при обработке всей таблицы я не надеваюНе вижу много места для оптимизации производительности самого запроса.Одна незначительная вещь: 

SELECT d.the_date
     , <b>generate_series(d.the_date - last_observed
                     , d.the_date - first_observed) AS days_to_date</b>
     , round(avg(price)) AS price
     , area_id
FROM   table_example
     , (SELECT date '2019-01-19') AS d(the_date)
GROUP  BY days_to_date, area_id;

Предполагая, что first_observed & last_observed равны date NOT NULL и всегда < date '2019-01-19'.Иначе вам нужно разыграть / сделать больше.

Таким образом, у вас есть только два вычитания, а затем generate_series() работает с целыми числами (быстрее всего).

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

     , (SELECT date '2019-01-19') AS d(the_date)

Кроме этого, если EXPLAIN (ANALYZE, BUFFERS) упоминает «Диск» (пример: Sort Method: external merge Disk: 3240kB), то(временное) более высокое значение для work_mem должно помочь.См .:

Если вы не можете позволить себе больше оперативной памяти, а этапы агрегирования и / или сортировки по-прежнему перетекают на диск, это может помочь разделить и победить с помощью запроса, например, с помощью LATERAL объединения: 

SELECT d.the_date, f.*, a.area_id
FROM   area a
     , (SELECT date '2019-01-19') AS d(the_date)
     , LATERAL (
   SELECT generate_series(d.the_date - last_observed
                        , d.the_date - first_observed) AS days_to_date
        , round(avg(price)) AS price
   FROM   table_example
   WHERE  area_id = a.area_id
   GROUP  BY 1
   ) f;

Принимая таблицу area, очевидно.

...