Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
Cc: Stanislaw Pankevich <s(dot)pankevich(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.
Date: 2012-07-06 11:38:56
Message-ID: CAAZKuFbpYyfRA=+DKD4yCr_c_Tag2JNO32B8NVU15gg4xX3u_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Jul 6, 2012 at 4:29 AM, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> wrote:
> 1) Truncate each table. It is too slow, I think, especially for empty
> tables.
>
> Really?!? TRUNCATE should be extremely fast, especially on empty tables.
>
> You're aware that you can TRUNCATE many tables in one run, right?
>
> TRUNCATE TABLE a, b, c, d, e, f, g;

I have seen in "trivial" cases -- in terms of data size -- where
TRUNCATE is much slower than a full-table DELETE. The most common use
case for that is rapid setup/teardown of tests, where it can add up
quite quickly and in a very big way. This is probably an artifact the
speed of one's file system to truncate and/or unlink everything.

I haven't tried a multi-truncate though. Still, I don't know a
mechanism besides slow file system truncation time that would explain
why DELETE would be significantly faster.

--
fdr

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Albe Laurenz 2012-07-06 13:10:51 Re: how could select id=xx so slow?
Previous Message Craig Ringer 2012-07-06 11:35:07 Re: PostgreSQL db, 30 tables with number of rows < 100 (not huge) - the fastest way to clean each non-empty table and reset unique identifier column of empty ones.