Skip site navigation (1) Skip section navigation (2)

Re: Benchmark shows very slow bulk delete

From: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
To: Ivan Voras <ivoras(at)freebsd(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Benchmark shows very slow bulk delete
Date: 2010-01-27 21:19:13
Message-ID: 4B60ADD1.80005@mansionfamily.plus.com (view raw or flat)
Thread:
Lists: pgsql-performance
Ivan Voras wrote:
> I wish that, when people got the idea to run a simplistic benchmark 
> like this, they would at least have the common sense to put the 
> database on a RAM drive to avoid problems with different cylinder 
> speeds of rotational media and fragmentation from multiple runs.
Huh?
> It's tough to benchmark anything involving rotational drives :)
But - how the database organises its IO to maximise the available 
bandwidth, limit
avaiodable seeks, and limit avoidable flushes is absolutely key to 
realistic performance,
especially on modest everyday hardware. Not everyone has a usage that 
justifies
'enterprise' kit - but plenty of people can benefit from something a 
step up from
SQLite.

If you just want to benchmark query processor efficiency then that's one 
scenario
where taking physical IO out of the picture might be justified, but I 
don't see a good
reason to suggest that it is 'common sense' to do so for all testing, 
and while the
hardware involved is pretty low end, its still a valid data point.
.



In response to

Responses

pgsql-performance by date

Next:From: Greg SmithDate: 2010-01-27 21:38:44
Subject: Re: Benchmark shows very slow bulk delete
Previous:From: Віталій ТимчишинDate: 2010-01-27 17:09:59
Subject: Re: Should the optimiser convert a CASE into a WHERE if it can?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group