Re :MySQL Benchmark page - Problem with vacuum() in PostgreSQL

From: Michael Widenius <monty(at)mysql(dot)com>
To: Mark kirkwood <markir(at)slingshot(dot)co(dot)nz>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re :MySQL Benchmark page - Problem with vacuum() in PostgreSQL
Date: 2001-08-17 12:15:36
Message-ID: 15229.2792.985845.797556@narttu.mysql.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Hi!

>>>>> "Mark" == Mark kirkwood <markir(at)slingshot(dot)co(dot)nz> writes:

Mark> Dear all,
Mark> Please humour me if this is a silly comment , or has been made before -
Mark> but....

Mark> when Monty posted the original message I had a few thoughts - ........

Mark> I understand that there is a issue with

Mark> loop many times
Mark> perform a set a updates/inserts
Mark> run vauuum
Mark> end loop

Mark> I would not peform a test this way.... let Postgresql MVCC sort out the
Mark> relevant rows to manage... so run vacuum once only....after all on a real
Mark> system you try to minimize the number of times vacuum ( or its related
Mark> equivalents in other dbms's - e.g : analyze ) are run ( as they are typically
Mark> expensive ).

Mark> So I guess I am saying that if the Benchmark requires multiple runs of vacuum
Mark> / analyze type functions then maybe the design of the benchmark should be
Mark> examined a bit...

The idea is to run the same benchmarks two different ways:

Normal: Run without any vacuum commands
Fast: Run vacuum after each massive update/insert batch

The reason for the 'fast' option is to get more accurate times for
system that is mostly 'read' oriented.

The test is more done like this:

- Do a lot of inserts
- vacuum
- Do a lot of updates/deletes
- vacuum
- Do a lot of selects
- drop tables

Vacuum is never performed in a loop.

In our tests we have noticed that we get a total speedup of 9 times
when doing vacuum this way.

Regards,
Monty

PS: The patch / new file we got from Tom Lane to fix the problem with
vacuum didn't help. I will do a complete bug report about this
later today.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mike Mascari 2001-08-17 12:16:32 Re: rotating table question
Previous Message Bruno Wolff III 2001-08-17 12:13:25 Re: Killing inactive connections