On Thu, Jul 20, 2017 at 12:16 PM, Sokolov Yura <funny.fal...@postgrespro.ru> wrote: > So, from my point of view, no one just evaluate performance of increased > ring buffer for vacuum.
I think that argument is clearly incorrect. In commit 6382448cf96a9b88d418cbaf86027b63f465b5d8, which you cited, Tom even added a note in the README file about why he didn't increase the value for vacuum also. He knew it would have increased performance had he also done it for BAS_BULKWRITE, and I knew it too, but it wasn't clear that it was a good idea, and it's still not. > But in fact, vacuum process performs FSYNC! It happens, cause vacuum > evicts dirty pages from its ring buffer. And to evict dirty page, it > has to be sure WAL record about its modification is FSYNC-ed to WAL. > Because ring buffer is damn small, vacuum almost always have to perform > FSYNC by itself and have to do it very frequently (cause ring is damn > small). > > With greater ring buffer, there is greater chance that fsync were > performed by wal_writer process, or other backend. And even if > vacuum does fsync by itself, it syncs records about more modified > pages from its ring, so evicting next page is free. OK, but I have helped *many* customers whose problem was that vacuum ran too fast and blew data out of the OS cache causing query response times to go through the roof. That's a common problem. Making VACUUM run faster will presumably make it more common. I've also run into many customers whose problem that vacuum ran too slowly, and generally raising vacuum_cost_limit fixes that problem just fine. So I don't think it's nearly as clear as you do that making VACUUM run faster is desirable. > If some fears that increasing vacuum ring buffer will lead to > decreasing transaction performance, then why it were not exhaustively > tested? If you want something changed, it's your job to do that testing. Asking why nobody else tested the effects of changing the thing you want changed is like asking why nobody else wrote the patch you want written. > And possible community will decide, that it should be GUC variable: > - if one prefers to keep its database unbloated, he could increase > vacuum ring buffer, > - otherwise just left it in "safe-but-slow" default. That's a possible outcome, but I don't think this discussion is really going anywhere unless you are willing to admit that increasing VACUUM performance could have some downsides. If you're not willing to admit that, there's not a lot to talk about here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
