Re: Inefficiency in parallel pg_restore with many tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inefficiency in parallel pg_restore with many tables
Дата
Msg-id 1225141.1690069670@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inefficiency in parallel pg_restore with many tables  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: Inefficiency in parallel pg_restore with many tables
Список pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Thu, Jul 20, 2023 at 12:06:44PM -0700, Nathan Bossart wrote:
>> One item that requires more thought is binaryheap's use of Datum.  AFAICT
>> the Datum definitions live in postgres.h and aren't available to frontend
>> code.  I think we'll either need to move the Datum definitions to c.h or to
>> adjust binaryheap to use "void *".

> In v3, I moved the Datum definitions to c.h.  I first tried modifying
> binaryheap to use "int" or "void *" instead, but that ended up requiring
> some rather invasive changes in backend code, not to mention any extensions
> that happen to be using it.

I'm quite uncomfortable with putting Datum in c.h.  I know that the
typedef is merely a uintptr_t, but this solution seems to me to be
blowing all kinds of holes in the abstraction, because exactly none
of the infrastructure that goes along with Datum is or is ever likely
to be in any frontend build.  At the very least, frontend code that
refers to Datum will be misleading as hell.

I wonder whether we can't provide some alternate definition or "skin"
for binaryheap that preserves the Datum API for backend code that wants
that, while providing a void *-based API for frontend code to use.

            regards, tom lane



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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: Inefficiency in parallel pg_restore with many tables
Следующее
От: jian he
Дата:
Сообщение: Re: PG 16 draft release notes ready