On Mon, Jul 15, 2019 at 1:35 PM Fabio Pardi <f.pa...@portavita.eu> wrote: > unlogged tables are not written to WAL, therefore checkpoints do not fit into > the picture (unless something else is writing data..).
That's my thought, and I was not expecting any big change in tps due to checkpoint_completion_target on unlogged tables. > It is not a good idea to have anything running in the background. Yes, I know, but the activity in the database is a task importing data on a per-schedule basis, always importing the same number of tuples (and therefore the same data size). In other words, it is a very constant and predictable workload. > > Also is always a good idea to run tests multiple times, and I think that 3 is > the bare minimum. > You want to make sure your tests are as reliable as possible, means having > similar results between each other, therefore you might post all the results, > not only the average, so people can give their interpretation of the data. > I'm trying to prepare a virual machine to run more tests in a completely isolated environment. But I was not trying to benchmarking the database, rather guessing what caused the different tps in such environment. > Assuming that the 'background activity' writes data, a value of > (checkpoint_completion_target) 0.9 means that when your test starts, the > system might be still busy in writing data from the previous checkpoint > (which started before your pgbench test was launched). That is less likely to > happen with a value of 0.1 Uhm...but in the logged table tests a value of 0.9 increases the tps, that as far as I understand is in contrast with what you are stating. Anyway, I'll test more and report back some more results. Thanks, Luca
