Re: pgsql 10: hash indexes testing
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, AP <ap@zip.com.au>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-04T17:58:10Z
Lists: pgsql-hackers
Robert Haas wrote: > I think this approach is actually better anyway. There's no guarantee > that VACUUM can be responsive enough to get the job done in time, work > items or no work items, Yeah, autovacuum work items don't have a guaranteed response time. They're okay for things that "ought to be done eventually", but if the condition causes a high-speed load to fail with errors, then halting the load until the cleanup is done seems like the way to go. Having to randomly inject pauses in your workload so that autovacuum has time to cope isn't great from the user's POV (a condition that is made worse if you don't have any mechanism to detect that you need a pause, or how long to pause for.) Once that part is working well, you could as a convenience (to avoid or reduce the stalls some of the time) add autovacuum work-item support. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
pgstatindex: Insert some casts to prevent overflow.
- 0b7ba3d6474b 10.0 cited
-
hash: Immediately after a bucket split, try to clean the old bucket.
- ff98a5e1e49d 10.0 landed
-
hash: Increase the number of possible overflow bitmaps by 8x.
- 620b49a16d2a 10.0 landed
-
BRIN auto-summarization
- 7526e10224f0 10.0 cited