Improve choose_custom_plan for initial partition prune case

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Improve choose_custom_plan for initial partition prune case
Дата
Msg-id CAKU4AWqUJmQdu9qf_pXxBYETkiXhTaXAQ_qtX7wxeLw27phdOw@mail.gmail.com
обсуждение исходный текст
Ответы Re: Improve choose_custom_plan for initial partition prune case  (Amit Langote <amitlangote09@gmail.com>)
Re: Improve choose_custom_plan for initial partition prune case  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список pgsql-hackers
Given the plan example: 

CREATE TABLE measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

CREATE TABLE measurement_y2006m02 PARTITION OF measurement
    FOR VALUES FROM ('2006-02-01') TO ('2006-03-01');

CREATE TABLE measurement_y2006m03 PARTITION OF measurement
    FOR VALUES FROM ('2006-03-01') TO ('2006-04-01');

prepare s as select * from measurement where logdate = $1;
execute s('2006-02-01').  

The generic plan will probably not be chosen because it doesn't reduce the cost
which can be reduced at initial_prune while the custom plan reduces such cost
at  planning time. which makes the cost comparison not fair.  I'm thinking if we can
get an estimated cost reduction of initial_prunne for generic plan based on the 
partition pruned at plan time from custom plan and then reducing
such costs from the generic plan.  I just went through the related code but
didn't write anything now.  I'd like to see if this is a correct direction to go.

--
Best Regards
Andy Fan

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Anastasia Lubennikova
Дата:
Сообщение: Re: [PATCH] Automatic HASH and LIST partition creation
Следующее
От: John Naylor
Дата:
Сообщение: Re: small cleanup: unify scanstr() functions