Re: [PoC] Reducing planning time when tables have many partitions

Поиск
Список
Период
Сортировка
От Yuya Watari
Тема Re: [PoC] Reducing planning time when tables have many partitions
Дата
Msg-id CAJ2pMkZrFS8EfvZpkw9CP0iqWk=EaAxzaKWS7dW+FTtqkUOWxA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PoC] Reducing planning time when tables have many partitions  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Ответы Re: [PoC] Reducing planning time when tables have many partitions  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Список pgsql-hackers
Hello,

Thank you for your reply.

On Thu, Aug 3, 2023 at 10:29 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> If you think that the verification is important to catch bugs, you may want to encapsulate it with an #ifdef ..
#endifsuch that the block within is not compiled by default. See OPTIMIZER_DEBUG for example. 

In my opinion, verifying the iteration results is only necessary to
avoid introducing bugs while developing this patch. The verification
is too excessive for regular development of PostgreSQL. I agree that
we should avoid a significant degradation in assert enabled builds, so
I will consider removing it.

> Do you think that the memory measurement patch I have shared in those threads is useful in itself? If so, I will
startanother proposal to address it. 

For me, who is developing the planner in this thread, the memory
measurement patch is useful. However, most users do not care about
memory usage, so there is room for consideration. For example, making
the metrics optional in EXPLAIN ANALYZE outputs might be better.

--
Best regards,
Yuya Watari



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

Предыдущее
От: José Neves
Дата:
Сообщение: RE: CDC/ETL system on top of logical replication with pgoutput, custom client
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: "duplicated" wait events