Доброго времени суток товарищи! Никто часом не юзал pg_pathman? Столкнулся

с такой проблемой, есть 2 таблицы со следующей структурой:
CREATE TABLE public.valuation (
id bigserial NOT NULL,
cost numeric(20,6) NULL,
discount numeric(20,6) NULL,
cost_with_vat numeric(20,6) NULL,
vat_sum numeric(20,6) NULL,
vat_rate_code text NULL,
currency_code text NOT NULL,
CONSTRAINT valuation_pkey PRIMARY KEY (id)
);

CREATE TABLE public.orders (
id uuid NOT NULL DEFAULT gen_random_uuid(),
"number" text NOT NULL,
paid_online_on_delivery_id int8 NULL,
CONSTRAINT orders_pkey PRIMARY KEY (id)
);

CREATE UNIQUE INDEX udx_orders_number ON public.orders USING btree (number);

Связь

valuation.id --> orders.paid_online_on_delivery_id (1 к 1)

Таблица valuation разбита на партиции по диапазонам. Ключ партиционирования - id. Всего 100 партиций.

Выполняю такой запрос

EXPLAIN (ANALYZE, BUFFERS)
SELECT
o.number,
v.id,
v.cost
FROM
orders o
JOIN valuation v ON v.id = o.paid_online_on_delivery_id
WHERE
o.number = '1104290452'

получаю

Planning time: 12748.652 ms
Execution time: 0.198 ms

Из результатов вижу, что на планирование запроса ушло целых 12 секунд 748 миллисекунд.

Если делаю тот же запрос указывая точную партицию, то получаю

Planning time: 0.351 ms
Execution time: 0.083 ms

Время планирования резко уменьшилось до 0.351 миллисекунд. Получается, что в первом запросе 12 секунд потратилось на поиск нужной партиции

Но если делаю запрос без джойна, то время нормальное:
Planning time: 0.128 ms
Execution time: 0.029 ms

Никто с таким не сталкивался?

Я бы делал связываемые поля буквально одного типа, не просто совместимого. Для проверки закидонов планировщика можно поменять джойн на LEFT.