Re: Inefficiency in parallel pg_restore with many tables
От | Robert Haas |
---|---|
Тема | Re: Inefficiency in parallel pg_restore with many tables |
Дата | |
Msg-id | CA+TgmoYtJ+ad+ej=BCPWRNPyNoLy2R2O5wBSZUeyaQ54jrPk4A@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 |
On Tue, Jul 25, 2023 at 2:53 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > On Mon, Jul 24, 2023 at 12:00:15PM -0700, Nathan Bossart wrote: > > Here is a sketch of this approach. It required fewer #ifdefs than I was > > expecting. At the moment, this one seems like the winner to me. > > Here is a polished patch set for this approach. I've also added a 0004 > that replaces the open-coded heap in pg_dump_sort.c with a binaryheap. > IMHO these patches are in decent shape. [ drive-by comment that hopefully doesn't cause too much pain ] In hindsight, I think that making binaryheap depend on Datum was a bad idea. I think that was my idea, and I think it wasn't very smart. Considering that people have coded to that decision up until now, it might not be too easy to change at this point. But in principle I guess you'd want to be able to make a heap out of any C data type, rather than just Datum, or just Datum in the backend and just void * in the frontend. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: