On 11/07/2014 05:29 PM, Alvaro Herrera wrote: > Josh Berkus wrote: >> Of course, this will lead to LOTs of additional vacuuming ... > > There's a trade-off here: more vacuuming I/O usage for less disk space > used. How stressed your customers really are about 1 GB of disk space?
These customers not so much. The users I encountered on chat whose pg_multixact was over 20GB, and larger than their database? Lots. On 11/08/2014 03:54 AM, Andres Freund wrote: > On 2014-11-07 17:20:44 -0800, Josh Berkus wrote: >> So the basic problem is that multixact files are just huge, with an >> average of 35 bytes per multixact? > > Depends on the concurrency. The number of members is determined by the > number of xacts concurrenly locking a row.. Yeah, that leads to some extreme inflation for databases where FK conflicts are common though. On 11/08/2014 03:54 AM, Andres Freund wrote: > On 2014-11-07 17:20:44 -0800, Josh Berkus wrote: >> Of course, this will lead to LOTs of additional vacuuming ... > > Yes. And that's likely to cause much, much more grief. > > Also. Didn't you just *vehemently* oppose making these values tunable at > all? Yes, I opposed adding a *user* tunable with zero information on how it should be tuned or why. I always do and always will. I also think our defaults for multixact freezing should be tied to the ones for xid freezing, and should not by default be completely independent numbers; I'm still not convinced that it makes sense to have a separate multixact threshold at all **since the same amount of vacuuming needs to be done regardless of whether we're truncating xids or mxids**. Certainly when I play with tuning this for customers, I'm going to lower vacuum_freeze_table_age as well. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
