Re: Ordered Partitioned Table Scans

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Ordered Partitioned Table Scans
Дата
Msg-id CAKJS1f-PAoC2PN3v54b_=5uyRsH5dQUO_i1By_BNozQTxxtQDw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Ordered Partitioned Table Scans  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Ordered Partitioned Table Scans
Список pgsql-hackers
On Thu, 28 Mar 2019 at 14:34, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> On 2019/03/28 7:29, David Rowley wrote:
> > On Wed, 27 Mar 2019 at 19:48, Amit Langote
> > It does need to know how many partitions the partitioned table has,
> > which it gets from partrel->nparts, so yeah, RelOptInfo is probably
> > needed. I don't think passing in int nparts is a good solution to
> > that.  The problem with moving it to partbounds.c is that nothing
> > there knows about RelOptInfo currently.
>
> Maybe, this could be a start.  Also, there is a patch in nearby thread
> which adds additional functionality to partbounds.c to be used by
> partitionwise join code in the optimizer [1].

Thanks for the review.  I've attached a patch that mostly just moved
the code around.

I also changed the comment in build_partition_pathkeys() to explain
about the nulls_first argument and why I just pass
ScanDirectionIsBackward(scandir).

Also, another comment in struct PlannerInfo to mentioning the
guarantee about append_rel_list having earlier partitions as defined
in PartitionDesc earlier in the list.

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

Вложения

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Log a sample of transactions
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: Re: reloption to prevent VACUUM from truncating empty pages atthe end of relation