X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 295A6D86CE for ; Tue, 30 Aug 2005 20:05:11 -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 95447-03 for ; Tue, 30 Aug 2005 23:05:04 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 826A4D86A6 for ; Tue, 30 Aug 2005 20:05:03 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j7UN54nF025547; Tue, 30 Aug 2005 19:05:04 -0400 (EDT) To: mark@mark.mielke.cc Cc: markus@m-bass.com, pgsql-performance@postgresql.org Subject: Re: When to do a vacuum for highly active table In-reply-to: <20050830220503.GA27740@mark.mielke.cc> References: <20050830211356.48138.qmail@web31606.mail.mud.yahoo.com> <24875.1125437357@sss.pgh.pa.us> <20050830220503.GA27740@mark.mielke.cc> Comments: In-reply-to mark@mark.mielke.cc message dated "Tue, 30 Aug 2005 18:05:03 -0400" Date: Tue, 30 Aug 2005 19:05:04 -0400 Message-ID: <25546.1125443104@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] X-Spam-Level: X-Archive-Number: 200508/549 X-Sequence-Number: 14296 mark@mark.mielke.cc writes: > I think he means splitting it vertically, instead of horizontally, and > it sounds like an excellent idea, if a large enough portion of each > record is in fact mostly fixed. Otherwise, PostgreSQL is copying data > multiple times, only to have the data expire as part of a dead row. Only up to a point. Fields that are wide enough to get toasted out-of-line (multiple Kb) do not get physically copied if there's a row update that doesn't affect them. We don't really have enough information about his table to guess whether there's any point in manually partitioning the columns, but my leaning would be "probably not" --- the overhead in joining the resulting two tables would be high enough that you'd need a heck of a big improvement to justify it. regards, tom lane