Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 2909A9FA463 for ; Fri, 15 Dec 2006 15:09:54 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 86852-10 for ; Fri, 15 Dec 2006 15:09:50 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id E70879FA456 for ; Fri, 15 Dec 2006 15:09:49 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kBFJ9mCX013948; Fri, 15 Dec 2006 14:09:48 -0500 (EST) To: "Steven Flatt" cc: pgsql-performance@postgresql.org Subject: Re: Insertion to temp table deteriorating over time In-reply-to: <357fa7590612151026t4ae033f6w5367cac9d0b67064@mail.gmail.com> References: <357fa7590612130844q58ef3ca5q31e164f9b006e0fc@mail.gmail.com> <9315.1166030958@sss.pgh.pa.us> <357fa7590612131517q375fc0by50cb4257bcce7a94@mail.gmail.com> <13032.1166052447@sss.pgh.pa.us> <357fa7590612141240t55e70695q770a05a68a67536c@mail.gmail.com> <25209.1166131396@sss.pgh.pa.us> <357fa7590612150821i3eca3f66ge2ced1ee20fa2dac@mail.gmail.com> <11651.1166202586@sss.pgh.pa.us> <357fa7590612150955g1b9c733duaf000c23d28aa8af@mail.gmail.com> <12508.1166206006@sss.pgh.pa.us> <357fa7590612151026t4ae033f6w5367cac9d0b67064@mail.gmail.com> Comments: In-reply-to "Steven Flatt" message dated "Fri, 15 Dec 2006 13:26:31 -0500" Date: Fri, 15 Dec 2006 14:09:48 -0500 Message-ID: <13947.1166209788@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/426 X-Sequence-Number: 22482 "Steven Flatt" writes: > Are the removable rows in pg_class even an issue? So what if 5000-6000 dead > tuples are generated every hour then vacuumed? Performance continues to > steadily decline over a few days time. Memory usage does not appear to be > bloating. Open file handles remain fairly fixed. Is there anything else I > can monitor (perhaps something to do with the odbc connection) that I could > potentially correlate with the degrading performance? At this point I think the most productive thing for you to do is to try to set up a self-contained test case that reproduces the slowdown. That would allow you to poke at it without disturbing your production system, and would let other people look at it too. From what you've said, I'd try a simple little program that inserts some data into a temp table, truncates the table, and repeats, as fast as it can, using the same SQL commands as your real code and similar but dummy data. It shouldn't take long to observe the slowdown if it occurs. If you can't reproduce it in isolation then we'll know that some other part of your application environment is contributing to the problem; if you can, I'd be happy to look at the test case with gprof or oprofile and find out exactly what's going on. regards, tom lane