Простой, но медленный SQL-запрос с PostgreSQL - PullRequest
Новая
       69

Простой, но медленный SQL-запрос с PostgreSQL

0 голосов
/ 27 февраля 2019

У меня есть две таблицы, к которым я хочу присоединиться: 

CREATE TABLE public."order" (
    id uuid NOT NULL,
    side varchar(4) NOT NULL,
    product varchar(7) NOT NULL,
    price numeric(18,8) NOT NULL,
    close_time timestamp NULL,
    CONSTRAINT order_pkey PRIMARY KEY (id)
);
CREATE TABLE public.order_history (
    id serial NOT NULL,
    amount numeric(18,8) NOT NULL,
    "time" timestamp NOT NULL,
    order_id uuid NOT NULL,
    CONSTRAINT order_history_pkey PRIMARY KEY (id),
    CONSTRAINT order_history_order_id_fkey FOREIGN KEY (order_id) REFERENCES "order"(id)
);
CREATE INDEX order_history_order_id ON public.order_history USING btree (order_id);
CREATE INDEX order_history_time_idx ON public.order_history USING btree ("time");

Мой запрос довольно прост, но он занимает буквально минуты на моем жестком диске (мой друг хранит одну и ту же БД на твердотельном накопителе и, очевидно,быстрее, но это все еще далеко за разумное время, я готов ждать): 

select
    "t1"."id",
    "t1"."side",
    "t1"."price",
    "t1"."close_time",
    "t2"."time",
    "t2"."amount"
from
    "order" as "t1"
inner join "order_history" as "t2" on
    ("t2"."order_id" = "t1"."id")
where
    ((("t2"."time" <= '2018-03-28 08:00:00')
    and (("t1"."close_time" > '2018-03-28 07:00:00')
    or ("t1"."close_time" is null)))
    and ("t1"."product" = 'BTC-USD'))
order by
    "t2"."time"

Вот вывод EXPLAIN(ANALYZE, BUFFERS): 

Gather Merge  (cost=3293333.15..3673129.97 rows=3255174 width=47) (actual time=195630.667..195668.246 rows=83766 loops=1)
  Workers Planned: 2
  Workers Launched: 2
  Buffers: shared hit=346185 read=948128, temp read=402275 written=402089
  ->  Sort  (cost=3292333.13..3296402.10 rows=1627587 width=47) (actual time=193748.573..193751.027 rows=27922 loops=3)
        Sort Key: t2."time"
        Sort Method: quicksort  Memory: 4853kB
        Buffers: shared hit=346185 read=948128, temp read=402275 written=402089
        ->  Hash Join  (cost=1315861.90..3074345.01 rows=1627587 width=47) (actual time=65363.240..193703.738 rows=27922 loops=3)
              Hash Cond: (t1.id = t2.order_id)
              Buffers: shared hit=346172 read=948127, temp read=402275 written=402089
              ->  Parallel Seq Scan on "order" t1  (cost=0.00..1293501.00 rows=11021971 width=34) (actual time=0.122..78296.478 rows=8629896 loops=3)
                    Filter: (((close_time > '2018-03-28 07:00:00'::timestamp without time zone) OR (close_time IS NULL)) AND ((product)::text = 'BTC-USD'::text))
                    Rows Removed by Filter: 19019229
                    Buffers: shared hit=13 read=775079
              ->  Hash  (cost=1079028.57..1079028.57 rows=12248346 width=29) (actual time=65107.372..65107.372 rows=12358141 loops=3)
                    Buckets: 524288  Batches: 32  Memory Usage: 27473kB
                    Buffers: shared hit=346071 read=173036, temp written=218295
                    ->  Bitmap Heap Scan on order_history t2  (cost=229265.25..1079028.57 rows=12248346 width=29) (actual time=2951.352..61701.142 rows=12358141 loops=3)
                          Recheck Cond: ("time" <= '2018-03-28 08:00:00'::timestamp without time zone)
                          Heap Blocks: exact=139266
                          Buffers: shared hit=346071 read=173036
                          ->  Bitmap Index Scan on order_history_time_idx  (cost=0.00..226203.16 rows=12248346 width=0) (actual time=2925.500..2925.500 rows=12358141 loops=3)
                                Index Cond: ("time" <= '2018-03-28 08:00:00'::timestamp without time zone)
                                Buffers: shared hit=67539 read=33770
Planning time: 0.444 ms
Execution time: 195672.969 ms

Понятия не имеюпочему этот простой запрос такой медленный, мне удалось немного ускорить его, создав индекс для order_history.time, но это все.Любое предложение приветствуется!

Ответы [ 2 ]

0 голосов
/ 27 февраля 2019
  • time - неправильное имя для столбца (отметка времени!), Избегайте его
  • order - неправильное имя для таблицы, избегайте его
  • естьотсутствует индекс для `close_time '
  • , старайтесь избегать значений NULL в столбцах меток времени ( почти key-field), избегая вместо этого` ... OR xxx IS NULL
  • , вы можете использовать разумные значения по умолчанию, такие как now() или +/-infinity
  • , последний шаг сортировки может разрушить ваш план yuery.

Также: вам, вероятно, не нуженсуррогатный ключ id на order_history.Достаточно будет натурального ключа (order_id,ztime). 

\i tmp.sql

CREATE TABLE orders (
    id uuid NOT NULL
    , side varchar(4) NOT NULL
    , product varchar(7) NOT NULL
    , price numeric(18,8) NOT NULL
    , close_time timestamp NOT  NULL DEFAULT ('infinity'::timestamp)
    , CONSTRAINT order_pkey PRIMARY KEY (id)
);
CREATE TABLE order_history (
    id serial NOT NULL
    , amount numeric(18,8) NOT NULL
    , ztime timestamp NOT NULL  DEFAULT ('-infinity'::timestamp)
    , order_id uuid NOT NULL
    , CONSTRAINT order_history_pkey PRIMARY KEY (id)
    , CONSTRAINT order_history_order_id_fkey FOREIGN KEY (order_id) REFERENCES orders(id)
);

-- CREATE INDEX order_history_order_id ON order_history USING btree (order_id);
-- CREATE INDEX order_history_time_idx ON order_history USING btree (ztime);
CREATE INDEX order_history_order_id_ztime ON order_history USING btree (order_id,ztime);
CREATE INDEX order_h_ztime ON orders USING btree (close_time);

EXPLAIN
select
    oo.id
    , oo.side
    , oo.price
    , oo.close_time
    , oh.ztime
    , oh.amount
from
    orders as oo
inner join order_history as oh on oh.order_id = oo.id
where oh.ztime <= '2018-03-28 08:00:00'
    and (oo.close_time > '2018-03-28 07:00:00' ) -- or oo.close_time is null)
    and oo.product = 'BTC-USD'
order by oh.ztime
        ;

Результирующий план (без каких-либо данных !!!): 

                                                       QUERY PLAN                                                       
------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=16.98..16.99 rows=1 width=92)
   Sort Key: oh.ztime
   ->  Nested Loop  (cost=3.14..16.98 rows=1 width=92)
         ->  Bitmap Heap Scan on orders oo  (cost=1.94..13.64 rows=1 width=64)
               Recheck Cond: (close_time > '2018-03-28 07:00:00'::timestamp without time zone)
               Filter: ((product)::text = 'BTC-USD'::text)
               ->  Bitmap Index Scan on order_h_ztime  (cost=0.00..1.94 rows=213 width=0)
                     Index Cond: (close_time > '2018-03-28 07:00:00'::timestamp without time zone)
         ->  Bitmap Heap Scan on order_history oh  (cost=1.20..3.33 rows=2 width=44)
               Recheck Cond: ((order_id = oo.id) AND (ztime <= '2018-03-28 08:00:00'::timestamp without time zone))
               ->  Bitmap Index Scan on order_history_order_id_ztime  (cost=0.00..1.20 rows=2 width=0)
                     Index Cond: ((order_id = oo.id) AND (ztime <= '2018-03-28 08:00:00'::timestamp without time zone))
(12 rows)
0 голосов
/ 27 февраля 2019

Ваш запрос набирает много данных, поэтому можно ожидать, что он будет медленным.

Последовательное сканирование на order - самый быстрый метод, поскольку вам нужна половина строк в таблице.

В целом, PostgreSQL должен прочитать более миллиона блоков, чтобы вычислить результат и обработать все эти данные, поэтому три минуты неплохо.

Я сомневаюсь, что этот запрос может быть выполнен быстрее.

...