Re: Improvements in pg_dump/pg_restore toc format and performances

2024-01-14 Thread vignesh C
On Fri, 10 Nov 2023 at 23:20, Nathan Bossart wrote: > > On Tue, Oct 03, 2023 at 03:17:57PM +0530, vignesh C wrote: > > Few comments: > > Pierre, do you plan to submit a new revision of this patch set for the > November commitfest? If not, the commitfest entry may be marked as > returned-with-feed

Re: Improvements in pg_dump/pg_restore toc format and performances

2023-11-10 Thread Nathan Bossart
On Tue, Oct 03, 2023 at 03:17:57PM +0530, vignesh C wrote: > Few comments: Pierre, do you plan to submit a new revision of this patch set for the November commitfest? If not, the commitfest entry may be marked as returned-with-feedback soon. -- Nathan Bossart Amazon Web Services: https://aws.am

Re: Improvements in pg_dump/pg_restore toc format and performances

2023-10-03 Thread vignesh C
On Tue, 19 Sept 2023 at 15:46, Pierre Ducroquet wrote: > > On Monday, September 18, 2023 11:54:42 PM CEST Nathan Bossart wrote: > > On Mon, Sep 18, 2023 at 02:52:47PM -0700, Nathan Bossart wrote: > > > On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote: > > >> I ended up writing seve

Re: Improvements in pg_dump/pg_restore toc format and performances

2023-09-20 Thread Nathan Bossart
On Tue, Sep 19, 2023 at 12:15:55PM +0200, Pierre Ducroquet wrote: > Attached updated patches fix this regression, I'm sorry I missed that. Thanks for the new patches. 0001 and 0002 look reasonable to me. This is a nitpick, but we might want to use atooid() in 0002, which is just shorthand for th

Re: Improvements in pg_dump/pg_restore toc format and performances

2023-09-19 Thread Pierre Ducroquet
On Monday, September 18, 2023 11:54:42 PM CEST Nathan Bossart wrote: > On Mon, Sep 18, 2023 at 02:52:47PM -0700, Nathan Bossart wrote: > > On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote: > >> I ended up writing several patches that shaved some time for pg_restore > >> -l, > >> and

Re: Improvements in pg_dump/pg_restore toc format and performances

2023-09-19 Thread Pierre Ducroquet
On Monday, September 18, 2023 11:54:42 PM CEST Nathan Bossart wrote: > On Mon, Sep 18, 2023 at 02:52:47PM -0700, Nathan Bossart wrote: > > On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote: > >> I ended up writing several patches that shaved some time for pg_restore > >> -l, > >> and

Re: Improvements in pg_dump/pg_restore toc format and performances

2023-09-18 Thread Pierre Ducroquet
On Monday, September 18, 2023 11:52:47 PM CEST Nathan Bossart wrote: > On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote: > > I ended up writing several patches that shaved some time for pg_restore > > -l, > > and reduced the toc.dat size. > > I've only just started taking a look at

Re: Improvements in pg_dump/pg_restore toc format and performances

2023-09-18 Thread Nathan Bossart
On Mon, Sep 18, 2023 at 02:52:47PM -0700, Nathan Bossart wrote: > On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote: >> I ended up writing several patches that shaved some time for pg_restore -l, >> and reduced the toc.dat size. > > I've only just started taking a look at these pat

Re: Improvements in pg_dump/pg_restore toc format and performances

2023-09-18 Thread Nathan Bossart
On Thu, Jul 27, 2023 at 10:51:11AM +0200, Pierre Ducroquet wrote: > I ended up writing several patches that shaved some time for pg_restore -l, > and reduced the toc.dat size. I've only just started taking a look at these patches, and I intend to do a more thorough review in the hopefully-not-too

Improvements in pg_dump/pg_restore toc format and performances

2023-07-27 Thread Pierre Ducroquet
Hi Following the thread "Inefficiency in parallel pg_restore with many tables", I started digging into why the toc.dat files are that big and where time is spent when parsing them. I ended up writing several patches that shaved some time for pg_restore -l, and reduced the toc.dat size. First