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.
