aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gist.c
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2014-10-03 13:01:27 -0300
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2014-10-03 13:01:27 -0300
commit06646f52ea43ba7ac7e89a2bc2e4493539e805e8 (patch)
treea91ee8efdf38337274a550b608c678020ce82a4a /src/backend/access/gist/gist.c
parentf270a1611026616d1304d4623f7e7acd0d6c63d6 (diff)
downloadpostgresql-06646f52ea43ba7ac7e89a2bc2e4493539e805e8.tar.gz
postgresql-06646f52ea43ba7ac7e89a2bc2e4493539e805e8.zip
Don't balance vacuum cost delay when per-table settings are in effect
When there are cost-delay-related storage options set for a table, trying to make that table participate in the autovacuum cost-limit balancing algorithm produces undesirable results: instead of using the configured values, the global values are always used, as illustrated by Mark Kirkwood in http://www.postgresql.org/message-id/52FACF15.8020507@catalyst.net.nz Since the mechanism is already complicated, just disable it for those cases rather than trying to make it cope. There are undesirable side-effects from this too, namely that the total I/O impact on the system will be higher whenever such tables are vacuumed. However, this is seen as less harmful than slowing down vacuum, because that would cause bloat to accumulate. Anyway, in the new system it is possible to tweak options to get the precise behavior one wants, whereas with the previous system one was simply hosed. This has been broken forever, so backpatch to all supported branches. This might affect systems where cost_limit and cost_delay have been set for individual tables.
Diffstat (limited to 'src/backend/access/gist/gist.c')
0 files changed, 0 insertions, 0 deletions