Re: Test to dump and restore objects left behind by regression
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, vignesh C <vignesh21@gmail.com>, Peter Eisentraut <peter@eisentraut.org>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-05T14:33:38Z
Lists: pgsql-hackers
Attachments
Hello, On 2025-Apr-04, Andres Freund wrote: > FWIW, with cassert and -O2, it's: > > 17: > real 0m53.981s > user 3m22.837s > sys 3m24.237s > > HEAD: > real 1m19.749s > user 4m54.526s > sys 4m15.657s > > so this isn't just due to me using -O0. A 48% increase is better than a 60% > increase, but it's still not sustainable. I happened to notice that this item was still open in the commitfest, and rereading the thread I now have second thoughts about having it enabled by default, giving your complaints about speed. How about applying this to 18 and master? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "This is a foot just waiting to be shot" (Andrew Dunstan)