On Thu, Jul 20, 2017 at 12:16 PM, Sokolov Yura
<funny.falcon@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