From: Tom Lane <tgl@sss.pgh.pa.us>
To: Steven Flatt <steven.flatt@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Insertion to temp table deteriorating over time
Date: Wed, 13 Dec 2006 18:44:47 -0500
Message-ID: <13154.1166053487@sss.pgh.pa.us> (raw)
In-Reply-To: <357fa7590612131517q375fc0by50cb4257bcce7a94@mail.gmail.com>
References: <357fa7590612130844q58ef3ca5q31e164f9b006e0fc@mail.gmail.com>
<9315.1166030958@sss.pgh.pa.us>
<357fa7590612131517q375fc0by50cb4257bcce7a94@mail.gmail.com>
"Steven Flatt" <steven.flatt@gmail.com> writes:
> Having said that, what kinds of things should I be looking for that could
> deteriorate/bloat over time? Ordinarily the culprit might be infrequent
> vacuuming or analyzing, but that wouldn't be corrected by a restart of
> Postgres. In our case, restarting Postgres gives us a huge performance
> improvement (for a short while, anyways).
> By the way, we are using PG 7.4.6 on FreeBSD 5.30.0170. The temp table has
> 15 columns: a timestamp, a double, and the rest integers. It has no
> indexes.
Hm, *are* you vacuuming only infrequently? In particular, what is your
maintenance policy for pg_class?
Some experimentation with TRUNCATE and VACUUM VERBOSE shows that in 7.4,
a TRUNCATE of a temp table with no indexes and no toast table generates
three dead row versions in pg_class. (I'm surprised that it's as many
as three, but in any case the TRUNCATE would certainly have to do one
update of the table's pg_class entry and thereby generate one dead row
version.)
If you're being sloppy about vacuuming pg_class, then over time the
repeated-truncate pattern would build up a huge number of dead rows
in pg_class, *all with the same OID*. It's unsurprising that this
would create some slowness in looking up the temp table's pg_class
entry.
If this theory is correct, the reason that starting a fresh backend
makes it fast again is that the new backend creates a whole new temp
table with a new OID assigned, and so the adjacent litter in pg_class
doesn't matter anymore (or not so much anyway).
Solution would be to institute regular vacuuming of the system
catalogs...
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, steven.flatt@gmail.com
Subject: Re: Insertion to temp table deteriorating over time
In-Reply-To: <13154.1166053487@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox