Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA78263 for ; Tue, 12 Oct 1999 11:18:17 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA16695; Tue, 12 Oct 1999 11:17:40 -0400 (EDT) To: "Steven M. Wheeler" cc: pgsql-sql@hub.org Subject: Re: [SQL] Questions about vacuum analyze In-reply-to: Your message of Tue, 12 Oct 1999 09:55:49 -0500 <38034BF5.AE40BBB4@sabre.com> Date: Tue, 12 Oct 1999 11:17:40 -0400 Message-ID: <16693.939741460@sss.pgh.pa.us> From: Tom Lane "Steven M. Wheeler" writes: > I tried your suggestion for -S 32 through -S 1 running a select > distinct against my history table. I normally run with -S 2048 on the > startup of the master process. FYI: the history table uses the same > layout as the currnt table, its just an hourly summation of the minute > by minute data in currnt. history has 189,724 records. > Bottom line: The select never failed. My current theory is that you were running out of disk space or else running up against a 4-gig-per-temp-file limit in the sort that's done for SELECT DISTINCT. So -S wouldn't really affect matters, and testing on a smaller table definitely won't prove anything one way or the other. BTW, I believe -S 32 is the smallest value the backend will actually accept --- it just ignores any attempt to set a smaller value. regards, tom lane