Received: from scully.sabre.com (scully.sabre.com [199.100.49.80]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA91609 for ; Tue, 12 Oct 1999 12:17:27 -0400 (EDT) (envelope-from swheeler@sabre.com) Received: from pop3.sabre.com (pop3.sabre.com [144.9.112.62]) by scully.sabre.com (8.9.3/8.9.3) with ESMTP id LAA12037 for ; Tue, 12 Oct 1999 11:16:56 -0500 (CDT) Received: from sabre.com ([172.29.63.42]) by pop3.sabre.com (Netscape Messaging Server 3.6) with ESMTP id AAA5748; Tue, 12 Oct 1999 11:16:43 -0500 Sender: smw@sabre.com Message-ID: <38035ECB.A89A13E8@sabre.com> Date: Tue, 12 Oct 1999 11:16:11 -0500 From: "Steven M. Wheeler" Organization: Mid-range UNIX Engineering, The SABRE Group X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.6 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tom Lane CC: pgsql-sql@hub.org Subject: Re: [SQL] Questions about vacuum analyze References: <3104.939393781@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Space taken up by entire DB: 6.7GB Space available on filesystem: 9.2GB Space taken by currnt table: 3.7GB Space taken by currnt index: 2.5GB Fluctuation of available space during a select distinct on the currnt table: max: 9.2GB, min: 4.1GB -- Steven Wheeler Mid-Range UNIX Engineering Sabre Inc. (918) 292-4119 Tom Lane wrote: > "Steven M. Wheeler" writes: > > I am now running into another problem. I need to do select distinct from the > > currnt to get dates for maintenance activity (rows to summarize and move to > > history). When ever I do I get this message in my server.log file: > > > NOTICE: BufFileRead: should have flushed after writing > > > And I get 0 records selected. > > After some code browsing I have come up with a theory: is it possible > that you are running out of disk space during the sort? I see psort.c > neglects to check for write failure :-(, although I am not entirely > clear on why that particular message and nothing else would come out > after it bulled ahead with an incomplete temporary file. > > Sorting a large table seems to require temp disk space equal to several > times the size of the table. Since you said your table is 40M rows, > I can easily believe you don't have that much free space... > > I don't believe anyone has taken a hard look at psort.c in a long time. > I will try to dive into it and see if its resource consumption can't > be reduced. Mergesort inherently requires 2X the original data space, > but it seems that psort is using even more than that, and perhaps this > can be improved. > > regards, tom lane