| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Subject: | Re: maintenance_work_mem used by Vacuum |
| Date: | 2019-10-07 20:17:53 |
| Message-ID: | CAH2-Wz=3hhc-hVi2DbxDW=AjB_7p0VRpvscrXyebTHukmfxBiw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 7, 2019 at 12:28 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I would say that sucks, because it makes it harder to set
> maintenance_work_mem correctly. Not sure how hard it would be to fix,
> though.
ginInsertCleanup() may now be the worst piece of code in the entire
tree, so no surprised that it gets this wrong too.
2016's commit e2c79e14d99 ripped out the following comment about the
use of maintenance_work_mem by ginInsertCleanup():
@@ -821,13 +847,10 @@ ginInsertCleanup(GinState *ginstate,
* Is it time to flush memory to disk? Flush if we are at the end of
* the pending list, or if we have a full row and memory is getting
* full.
- *
- * XXX using up maintenance_work_mem here is probably unreasonably
- * much, since vacuum might already be using that much.
*/
ISTM that the use of maintenance_work_mem wasn't given that much
thought originally.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Isaac Morland | 2019-10-07 21:38:15 | Re: PATCH: Add uri percent-encoding for binary data |
| Previous Message | Andres Freund | 2019-10-07 20:10:04 | Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros) |