| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, postgresql(at)taljaren(dot)se, pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) |
| Date: | 2022-12-29 18:52:14 |
| Message-ID: | 20221229185214.GA212944@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Wed, Dec 28, 2022 at 07:03:29PM -0800, Andres Freund wrote:
> Separately I wonder if it's worth micro-optimizing vac_update_datfrozenxid() a
> bit. I e.g. see a noticable speedup bypassing systable_getnext() and using
> heap_getnext(). It's really too bad that we want to check for "in the future"
> xids, otherwise we could use a ScanKey to filter at a lower level.
Another thing I'm exploring is looking up the datfrozenxid/datminmxid
before starting the pg_class scan so that the scan can be stopped early if
it sees that we cannot possibly advance the values. The
overwrite-corrupt-values logic might make this a little more complicated,
but I think it'd be sufficient to force the pg_class scan to complete if we
ever see a value "in the future." Overwriting the corrupt value might be
delayed, but it would eventually happen once the table ages advance.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-12-29 20:29:15 | Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) |
| Previous Message | Tom Lane | 2022-12-29 18:45:49 | Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-12-29 19:43:26 | Re: recovery modules |
| Previous Message | Tom Lane | 2022-12-29 18:51:37 | Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local |