It's a way of putting some tables, indexes, etc into a different part of your system's storage. Sometimes you want to do this to put a really big table on slower, cheaper storage. Sometimes you might want to put indexes on really fast but expensive or small and limited storage. It's also useful for splitting up tables that're often accessed concurrently so they're on different disk arrays and don't compete with each other for I/O. There are lots of uses.
2) one more issue is that, I try to rename or delete some file in /opt/PostgresPlus/9.0/data/base/16428/ directory.
Don't do that!
Do not mess with anything in the PostgreSQL data directory unless you know *EXACTLY* what you are doing.
when I restart postgres server, it start normally. but I thing this is wrong. I rename or delete file into above directory, that means my database(having 16428 oid) is corrupted. So How can my postgres server is started normally??
Because it hasn't needed to access that file yet. When it does, it'll report errors for attempts to access that file but will otherwise continue to function normally.
PostgreSQL doesn't try to verify the whole database on startup. Imagine how long that'd take!
I want to see the log file for that database corruption. Can I see it?? and where??? and please explain me that what's going on in above case??????
You need to figure out what you deleted by looking in pg_catalog, then attempt to access it.
It'd be nice if there were a built-in tool or utility to verify a database catalog against the on-disk contents, but it's never supposed to be necessary. The need only arises when someone does something silly or when a file system goes bad - and in the latter case, who says it's the catalog that's correct?
