Re: Maintenance question / DB size anomaly...

OOooooookaaaaaaaaay. Since the discussion has wandered a bit I just
wanted to restate things in an effort to clear the problem in my head.

Okay, so the sl_log_1 TABLE looks okay. Its the indexes that seem to
be messed up, specifically sl_log_1_idx1 seems to think that there's
> 300,000 rows in the table its associated with. I just want to fix
the index, really. So my question remains:

Its it okay to dump and recreate that index (or reindex it) while the
servers are down and the database is not being accessed?

Tom, Bill, Chris and Richard, thank you so much for your thoughts on
this matter so far. It helps to not feel "so alone" when dealing
with difficult issues (for me anyway) on a system I don't know so
much about.

Thanks guys,

/kurt

On Jun 19, 2007, at 10:51 PM, Tom Lane wrote:

> Kurt Overberg <kurt(at)hotdogrecords(dot)com> writes:
>> Okay, I've grabbed pg_filedump and got it running on the appropriate
>> server.
>> I really have No Idea how to read its output though. Where does the
>> ctid from sl_log_1
>> appear in the following listing?
>
> ctid is (block number, item number)
>
>> Block 0 ********************************************************
>> BTree Meta Data: Magic (0x00053162) Version (2)
>> Root: Block (1174413) Level (3)
>> FastRoot: Block (4622) Level (1)
>
> This seems to be an index, not the sl_log_1 table.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend