"Steven Flatt" <[EMAIL PROTECTED]> writes: > Any idea where the bloat is happening? I believe that if we were dropping > and re-creating the temp table over and over, that could result in pg_class > bloat (among other catalog tables), but what is going wrong if we use the > same table over and over and truncate it?
That seems very strange --- I too would have expected a TRUNCATE to bring you back to ground zero performance-wise. I wonder whether the issue is not directly related to the temp table but is just some generic resource leakage problem in a very long-running backend. Have you checked to see if the backend process bloats memory-wise, or perhaps has a huge number of files open (I wonder if it could be leaking open file handles to the successive generations of the temp table)? Are you sure that the slowdown is specific to inserts into the temp table, as opposed to generic SQL activity? Also, which PG version is this exactly ("7.4" is not specific enough)? On what platform? Can you show us the full schema definition for the temp table and any indexes on it? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings