Re: [Sender Address Forgery]Re: [HACKERS] path toward fasterpartition pruning

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: [Sender Address Forgery]Re: [HACKERS] path toward fasterpartition pruning
Дата
Msg-id cfba3fb0-b121-7e70-acc9-b477dc71e2de@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: [Sender Address Forgery]Re: [HACKERS] path toward fasterpartition pruning
Список pgsql-hackers
Hi.

On 2018/01/12 18:09, David Rowley wrote:
> On 10 January 2018 at 17:18, David Rowley <david.rowley@2ndquadrant.com> wrote:
>> Basically, the changes to add_paths_to_append_rel() are causing
>> duplication in partition_rels.

[ ... ]

> I also noticed earlier that this is still broken in v19.

I cannot see the duplication here (with v19 + some local changes per your
latest review, although I had fixed the issue in v18).

create table part (a int, b int) partition by list(a);
create table part1 partition of part for values in (1) partition by list (b);
create table part2 partition of part1 for values in (1);

select * from part;

For the above query, I set a breakpoint all the way in ExecInitAppend() to
see what partitioned_rels list it ends up with and I see no duplication:

   :partitioned_rels (i 1 3)

where 1 and 3 are RT indexes of part and part1, respectively.

With v17, you'd be able to see the duplication:

   :partitioned_rels (i 1 3 3)

Let me confirm again if you were complaining exactly of this duplication?
That the RT index of part1 appears twice due to the bug I claim I fixed i
v18?  Or something else?

Thanks,
Amit



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

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: [HACKERS] A design for amcheck heapam verification
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: CREATE ROUTINE MAPPING