Обсуждение: Re :MySQL Benchmark page - Problem with vacuum() in PostgreSQL

Dear all,

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

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

I understand that there is a issue with

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

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

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


regards

Mark

Sounds eminently reasonable.... my misunderstanding sorry :-(

regards,
Mark

On Saturday 18 August 2001 00:15, Michael Widenius wrote:
> Hi!
>
> 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.

Hi!

>>>>> "Mark" == Mark kirkwood <markir@slingshot.co.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.