Thank you Scott and Lonni for your replies ...
On Fri, 2005-04-01 at 11:21, David Link wrote:
I have a question regarding filesystem disk space usage.
We have a production database containing 5 years of sales data.
Linux 2.6.5; Postgresq 7.4.7. VACUUM ANALZYE the entire database
everynight (abou
On Fri, 2005-04-01 at 11:21, David Link wrote:
> Greetings worthymen.
>
> I have a question regarding filesystem disk space usage.
>
> We have a production database containing 5 years of sales data.
> Linux 2.6.5; Postgresq 7.4.7. VACUUM ANALZYE the entire database
> everynight (about 40min).
On Apr 1, 2005 9:21 AM, David Link <[EMAIL PROTECTED]> wrote:
> Greetings worthymen.
>
> I have a question regarding filesystem disk space usage.
>
> We have a production database containing 5 years of sales data.
> Linux 2.6.5; Postgresq 7.4.7. VACUUM ANALZYE the entire database
> everynight (a
Greetings worthymen.
I have a question regarding filesystem disk space usage.
We have a production database containing 5 years of sales data.
Linux 2.6.5; Postgresq 7.4.7. VACUUM ANALZYE the entire database
everynight (about 40min).
It's size, @SUM(pg_class.relpages) * 8192K, is ...
About 66 G
Jeff MacDonald <[EMAIL PROTECTED]> writes:
> well, i did a "delete from email_log" and then a vacuum and the files
> are still lingering around...
TRUNCATE would be better. A VACUUM FULL would shrink the tables all
right, but probably not do much for the indexes.
regards,
VACUUM or VACUUM FULL. Only the second actually reclaims diskspace...
On Mon, Dec 20, 2004 at 03:21:51PM -0400, Jeff MacDonald wrote:
> well, i did a "delete from email_log" and then a vacuum and the files
> are still lingering around...
>
> still huge. the postmaster did die due to a diskspace i
well, i did a "delete from email_log" and then a vacuum and the files
are still lingering around...
still huge. the postmaster did die due to a diskspace issue, so i
wonder if it's still just keeping a wierd lock on those files or
something.. idea's ?
On Mon, 20 Dec 2004 11:01:32 -0300, Alvaro H
On Mon, Dec 20, 2004 at 09:57:35AM -0400, Jeff MacDonald wrote:
> # select relname,relfilenode,relpages from pg_class where relfilenode
> = 13312279;
> relname | relfilenode | relpages
> ---+-+--
> email_log |13312279 |36821
>
> It just so happens that em
pg_class tells me
select relname,relfilenode,relpages from pg_class where relfilenode = 13312283;
relname | relfilenode | relpages
---+-+--
pg_toast_13312279 |13312283 | 367639
So now I guess I have to find out what 13312279 is..
Ah HA !
On Mon, Dec 20, 2004 at 09:48:57AM -0400, Jeff MacDonald wrote:
> I'm using 7.3.4
And what about pg_class?
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"Industry suffers from the managerial dogma that for the sake of stability
and continuity, the company should be independent of the competence of
ind
I'm using 7.3.4
Jeff.
On Mon, 20 Dec 2004 10:48:18 -0300, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> On Mon, Dec 20, 2004 at 09:39:15AM -0400, Jeff MacDonald wrote:
>
> Hi,
>
> > select * from pg_statio_user_tables where relid = 13312283;
>
> See the pg_class table, using the relfilenode col
On Mon, Dec 20, 2004 at 09:39:15AM -0400, Jeff MacDonald wrote:
Hi,
> select * from pg_statio_user_tables where relid = 13312283;
See the pg_class table, using the relfilenode column.
> So I guess my question is, how do i find out what 13312283.* are, are
> they safe to delete ?
Probably none.
Hi,
We after some more reading I learned that this huge file is my TOAST table..
Is there a way to schrink that down ?
Thanks.
Jeff.
On Mon, 20 Dec 2004 09:39:15 -0400, Jeff MacDonald <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a database that is about 3.5 gigs big. And I have a pretty
> ser
Hi,
I have a database that is about 3.5 gigs big. And I have a pretty
serious hunch that there isn't that much data.
I did a "du -s *|sort -n " in /usr/local/pgsql/data/base/9039913
And got a list that ends with these entries.
55648 18070582
137296 13312252
294736 13312279
845648 13312283.
14 matches
Mail list logo
