X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id F0E9B52A81 for ; Sat, 6 Aug 2005 10:16:12 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 59717-09 for ; Sat, 6 Aug 2005 13:16:03 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by svr1.postgresql.org (Postfix) with ESMTP id 5C64F52A73 for ; Sat, 6 Aug 2005 10:16:02 -0300 (ADT) Received: from [127.0.0.1] (c-24-4-66-2.hsd1.ca.comcast.net[24.4.66.2]) by comcast.net (sccrmhc13) with ESMTP id <2005080613160501300dkqnbe>; Sat, 6 Aug 2005 13:16:05 +0000 Message-ID: <42F4B812.7070501@comcast.net> Date: Sat, 06 Aug 2005 06:16:02 -0700 From: Patrick Hatcher User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "pgsql-performance@postgresql.org" Subject: Slow update statement Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=2.22 tagged_above=0 required=5 tests=DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, TO_ADDRESS_EQ_REAL X-Spam-Level: ** X-Archive-Number: 200508/54 X-Sequence-Number: 13801 [Reposted from General section with updated information] Pg 7.4.5 I'm running an update statement on about 12 million records using the following query: Update table_A set F1 = b.new_data from table_B b where b.keyfield = table_A.keyfield both keyfields are indexed, all other keys in table_A were dropped, yet this job has been running over 15 hours. Is this normal? I stopped the process the first time after 3 hours of running due to excessive log rotation and reset the conf file to these settings: wal_buffers = 64 # min 4, 8KB each # - Checkpoints - checkpoint_segments = 128 # in logfile segments, min 1, 16MB each checkpoint_timeout = 1800 # range 30-3600, in seconds #checkpoint_warning = 30 # 0 is off, in seconds #commit_delay = 0 # range 0-100000, in microseconds #commit_siblings = 5 # range 1-1000 Would it just be quicker to run a JOIN statement to a temp file and then reinsert? TIA Patrick