Re: [HACKERS] Runtime Partition Pruning

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: [HACKERS] Runtime Partition Pruning
Дата
Msg-id CAKJS1f_jejNN7Tw-E95MD0W-4PtxEjsDYKNvJATEoLz0sJou+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: [HACKERS] Runtime Partition Pruning  (Beena Emerson <memissemerson@gmail.com>)
Список pgsql-hackers
Hi,

Please find attached my 4th version this patch.

This is now based on v17 of Amit's faster partition pruning patch [1].
It also now includes Beena's tests which I've done some mostly
cosmetic changes to.

I've also fixed a few bugs, one in a case where I was not properly
handling zero matching partitions in nodeAppend.c.

Another change I've made is to now perform the partition pruning at
run-time using a new memory context that's reset each time we
redetermine the matching partitions. This was required since we're
calling a planner function which might not be too careful about
pfreeing memory it allocates. A test case I was running before making
this change ended out failing to palloc memory due to OOM.

I've not done anything about reducing the cost of the Append path when
runtime pruning is enabled. I'm still thinking over the best way to
handle that.

[1] https://www.postgresql.org/message-id/58c3e20a-a964-4fdb-4e7d-bd833e9bead1@lab.ntt.co.jp

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

Вложения

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

Предыдущее
От: Jeremy Finzel
Дата:
Сообщение: Re: Deadlock between concurrent index builds on different tables
Следующее
От: David Fetter
Дата:
Сообщение: Re: AS OF queries