| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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-28 21:21:50 |
| Message-ID: | 20221228212150.GA4009813@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Wed, Dec 28, 2022 at 03:13:23PM -0500, Tom Lane wrote:
> + /* If we used SKIP_DATABASE_STATS, mop up with ONLY_DATABASE_STATS */
> + if (vacopts->skip_database_stats && stage == ANALYZE_NO_STAGE && !failed)
> + {
> + executeCommand(conn, "VACUUM (ONLY_DATABASE_STATS);", echo);
> + }
When I looked at this, I thought it would be better to send the command
through the parallel slot machinery so that failures would use the same
code path as the rest of the VACUUM commands. However, you also need to
adjust ParallelSlotsWaitCompletion() to mark the slots as idle so that the
slot array can be reused after it is called.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-12-28 21:23:21 | Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) |
| Previous Message | Tom Lane | 2022-12-28 21:20:19 | 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-28 21:23:21 | Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) |
| Previous Message | Tom Lane | 2022-12-28 21:20:19 | Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) |