Tom Lane wrote:
> Thus the timing issue (at least as exhibited by this script) has nothing
> whatever to do with the time to delete a file, but with the time to
> create one. Since the part of DROP being timed has probably got no I/O
> involved at all (the tuples being touched are almost surely still in
> shared buffers), it's unsurprising that it is consistently fast.
In my original profiling, CREATE TEMPORARY TABLE/DROP TABLE wasn't much faster than TRUNCATE TABLE.
When I try it again now, I see that DROP TABLE is consistently fast, while the timings of CREATE
TEMPORARY TABLE vary as much as those of TRUNCATE TABLE. Your observations on the time needed to
open a file confirm that, I think.
In my test databases, autovacuum is off.
Adriaan van Os
In response to
pgsql-performance by date
|Next:||From: Heikki Linnakangas||Date: 2007-07-18 08:57:15|
|Subject: Re: importance of fast disks with pg|
|Previous:||From: Ron Mayer||Date: 2007-07-17 22:29:32|
|Subject: ionice to make vacuum friendier?|