Re: [SQL] Questions about vacuum analyze

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Steven M(dot) Wheeler" <swheeler(at)sabre(dot)com>
Cc: pgsql-sql(at)hub(dot)org
Subject: Re: [SQL] Questions about vacuum analyze
Date: 1999-10-12 18:07:28
Message-ID: 17344.939751648@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"Steven M. Wheeler" <swheeler(at)sabre(dot)com> writes:
> 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

OK, so you're not running out of space, but it could easy be that you
are hitting the limit on temp file size --- which is likely either 2 or
4Gb depending on whether your OS uses unsigned arithmetic for file
offsets.

Can you watch the pg_sorttempNNNN.NN files in the database directory and
see how large they get during the sort? There should be seven of 'em
generated by the sorting process, and at least one needs to grow to
reach the same size as the table (more or less).

BTW, I have some code which solves this problem by splitting large
temporary sort files into segments, just as we do for the tables
themselves ... but it's not even well-tested enough to commit to current
yet, let alone backpatch into 6.5.* ;-)

regards, tom lane

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 1999-10-12 20:57:06 Re: [SQL] security: escaping user-supplied data
Previous Message Steven M. Wheeler 1999-10-12 16:16:11 Re: [SQL] Questions about vacuum analyze