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)
Список
Дерево обсуждения
Inefficiency in parallel pg_restore with many tables Tom Lane <tgl@sss.pgh.pa.us>
Re: Inefficiency in parallel pg_restore with many tables Pierre Ducroquet <p.psql@pinaraf.info>
Re: Inefficiency in parallel pg_restore with many tables Andres Freund <andres@anarazel.de>
Re: Inefficiency in parallel pg_restore with many tables Andrew Dunstan <andrew@dunslane.net>
Re: Inefficiency in parallel pg_restore with many tables Tom Lane <tgl@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 Nathan Bossart <nathandbossart@gmail.com>
Re: Inefficiency in parallel pg_restore with many tables Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: Inefficiency in parallel pg_restore with many tables Nathan Bossart <nathandbossart@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 Nathan Bossart <nathandbossart@gmail.com>
Re: Inefficiency in parallel pg_restore with many tables Tom Lane <tgl@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 Nathan Bossart <nathandbossart@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 Nathan Bossart <nathandbossart@gmail.com>
Re: Inefficiency in parallel pg_restore with many tables Tom Lane <tgl@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 Robert Haas <robertmhaas@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 Nathan Bossart <nathandbossart@gmail.com>
Re: Inefficiency in parallel pg_restore with many tables Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: Inefficiency in parallel pg_restore with many tables Nathan Bossart <nathandbossart@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 Tom Lane <tgl@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 Nathan Bossart <nathandbossart@gmail.com>
Re: Inefficiency in parallel pg_restore with many tables Tom Lane <tgl@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 Nathan Bossart <nathandbossart@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 Tom Lane <tgl@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 Tom Lane <tgl@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 Michael Paquier <michael@paquier.xyz>
Re: Inefficiency in parallel pg_restore with many tables Nathan Bossart <nathandbossart@gmail.com>
Nathan Bossart 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
Дата: