Re: Big 7.1 open items
От | Bruce Momjian |
---|---|
Тема | Re: Big 7.1 open items |
Дата | |
Msg-id | 200006271818.OAA29260@candle.pha.pa.us обсуждение исходный текст |
Ответ на | RE: Big 7.1 open items ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Список | pgsql-hackers |
[ Charset ISO-8859-1 unsupported, converting... ] > > > > 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"). > > > > > > Our database design seems to be in the opposite direction > > > if it is restricted for the convenience of command calls. > > > > Well, I don't see any reason not to use tablespace/database > > rather than just tablespace. Seems having fewer files in each directory > > Once again - ability to use different tablespaces (disks) for tables/indices > in the same schema. Schemas must not dictate where to store objects <- > bad design. I am suggesting this symlink: ln -s data/base/testdb/myspace /var/myspace/testdb rather than: ln -s data/base/testdb/myspace /var/myspace Tablespaces still sit inside database directories, it is just that it points to a subdirectory of myspace, rather than myspace itself. Am I missing something? > > > will be a little faster, and if we can make administration easier, > > why not? > > Because you'll not be able use du/ls once we'll implement new smgr anyway. At least du will work. I doubt we will be putting tables from different databases in the same file. > > And, btw, - for what are we going implement tablespaces? Just to have > fewer files in each dir ?! No, I thought it was to split files across drives. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: