RE: Big 7.1 open items
От | Mikheev, Vadim |
---|---|
Тема | RE: Big 7.1 open items |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A23018C38@SECTORBASE1 обсуждение исходный текст |
Ответ на | Big 7.1 open items (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
> > We could create /data/databases/DATABASEOID/ and create > > soft-links to table-files. This way different tables of > > the same database could be in different tablespaces. > > /data/database path would be used in production > > and /data/tablespace path would be used in recovery. > > Why would you want to do it that way? Having a different access path > for recovery than for normal operation strikes me as just asking for > trouble ;-) I just think that *databases* (schemas) must be used for *logical* groupping of tables, not for *physical* one. "Where to store table" is tablespace' related kind of things! > The symlinks wouldn't do any good for what Bruce had in mind anyway > (IIRC, he wanted to get useful per-database numbers from "du"). Imho, ability to put different tables/indices (of the same database) to different tablespaces (disks) is much more useful then ability to use du/ls for administration purposes -:) Also, I think that we *must* go away from OS' driven disk space allocation anyway. Currently, the way we extend table files breaks WAL rule (nothing must go to disk untill logged). + we have to move tuples from end of file to top to shrink relation - not perfect way to reuse empty space. +... +... +... Vadim
В списке pgsql-hackers по дате отправления: