Re: open/lseek overhead with many partitions (including with "fasterpartitioning pruning")

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: open/lseek overhead with many partitions (including with "fasterpartitioning pruning")
Дата
Msg-id CAKJS1f8nftTMNOCpZDtGa3P=CDPwHP-9nKDYr12C=3dbBmG+Bg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: open/lseek overhead with many partitions (including with "fasterpartitioning pruning")  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On 4 April 2018 at 12:31, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2018/04/04 9:27, David Rowley wrote:
>> Yeah, this will no doubt be due to the fact that we still build
>> RelOptInfos in the planner for all partitions, so we're still doing
>> get_relation_info() and estimate_rel_size() for each of those. It
>> might be possible to delay that call until we know we're going to need
>> the partition.  I imagine we wouldn't need to know the size of the
>> relation until after set_rel_sizes, but I've not checked.
>
> Yeah, one of the earliest patches on the "faster partition pruning" had
> tried to solve this issue, but we decided it was better to come to it
> after we're done dealing with just making the pruning faster.

Yeah, it'll need to be a PG12 project now.

It would be nice to not create the RelOptInfos at all until we've
decided we need them. Perhaps we can put NULL placeholders in
simple_rel_array... the major problem with that at the moment is that
the boundinfo stuff is stored in each relation and not the parent
partitioned table, so I think pruning could only take place after each
RelOptInfo has been built.  To fix that we'd need to store relation
Oids of partitioned tables along with their boundinfo in the parent's
RelOptInfo... Anyway, no doubt we'll get a chance to think harder on
this once PG11 is out the way.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: open/lseek overhead with many partitions (including with "fasterpartitioning pruning")
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Running Installcheck remotely