Re: help understanding pgbench results

From: Luca Ferrari <fluca1978(at)gmail(dot)com>
To: Fabio Pardi <f(dot)pardi(at)portavita(dot)eu>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: help understanding pgbench results
Date: 2019-07-15 13:14:38
Message-ID: CAKoxK+7Mmc-+-oU_4VQjPNOk_d2CmCuFpq60RHPZk2t2_ZyoGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jul 15, 2019 at 1:35 PM Fabio Pardi <f(dot)pardi(at)portavita(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Luca Ferrari 2019-07-15 13:21:28 after restore the size of the database is increased
Previous Message Pavel Stehule 2019-07-15 13:02:21 Re: CRecordset::Open postgresql procedure call don't work