aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/advanced.source
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2021-08-09 16:48:01 +1200
committerDavid Rowley <drowley@postgresql.org>2021-08-09 16:48:01 +1200
commit5c7522d111ed13e485f54af5cc247f39a6303e1b (patch)
tree3dad005c3db5c45935cc4cb925b5584db711a45f /src/tutorial/advanced.source
parentbe500101705c65104af41eaad5e36906b52f44b2 (diff)
downloadpostgresql-5c7522d111ed13e485f54af5cc247f39a6303e1b.tar.gz
postgresql-5c7522d111ed13e485f54af5cc247f39a6303e1b.zip
Doc: Fix misleading statement about VACUUM memory limits
In ec34040af I added a mention that there was no point in setting maintenance_work_limit to anything higher than 1GB for vacuum, but that was incorrect as ginInsertCleanup() also looks at what maintenance_work_mem is set to during VACUUM and that's not limited to 1GB. Here I attempt to make it more clear that the limitation is only around the number of dead tuple identifiers that we can collect during VACUUM. I've also added a note to autovacuum_work_mem to mention this limitation. I didn't do that in ec34040af as I'd had some wrong-headed ideas about just limiting the maximum value for that GUC to 1GB. Author: David Rowley Discussion: https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com Backpatch-through: 9.6, same as ec34040af
Diffstat (limited to 'src/tutorial/advanced.source')
0 files changed, 0 insertions, 0 deletions