diff options
| author | David Rowley <drowley@postgresql.org> | 2021-08-09 16:47:25 +1200 |
|---|---|---|
| committer | David Rowley <drowley@postgresql.org> | 2021-08-09 16:47:25 +1200 |
| commit | bb08e78972b1d0ec9f11f3d0b18903ec7a216855 (patch) | |
| tree | adab2ca7aeeaea3c6cca2a823e99ec218c4f4009 /src/backend/regex/regexec.c | |
| parent | ff18b8d1b169b2bf47daab7d92c5376bc19c0748 (diff) | |
| download | postgresql-bb08e78972b1d0ec9f11f3d0b18903ec7a216855.tar.gz postgresql-bb08e78972b1d0ec9f11f3d0b18903ec7a216855.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/backend/regex/regexec.c')
0 files changed, 0 insertions, 0 deletions