Re: Storage Location Patch Proposal for V7.3
От | Jim Buttafuoco |
---|---|
Тема | Re: Storage Location Patch Proposal for V7.3 |
Дата | |
Msg-id | 200111072143.fA7Lhh407522@dual.buttafuoco.net обсуждение исходный текст |
Ответ на | Storage Location Patch Proposal for V7.3 ("Jim Buttafuoco" <jim@buttafuoco.net>) |
Список | pgsql-hackers |
Mark, This is why I choose to use the term "LOCATION" instead of "TABLESPACE" . A "LOCATION" is a directory just like Postgresql has today. All the patch would add is the ability to put object under different "LOCATION" for the same database. Jim > Tom Lane wrote: > > > > "Jim Buttafuoco" <jim@buttafuoco.net> writes: > > > I propose to add a default data location, index and temporary locations > > > to the pg_shadow table to allow a DBA to specify locations for each > > > user when they create databases, tables and indexes or need temporary > > > disk storage (either for temporary tables or sort files). > > > > Have you read any of the previous discussions about tablespaces? > > This seems to be tablespaces with an off-the-cuff syntax. I'd > > suggest taking a hard look at Oracle's tablespace facility and > > seeing how closely we want to duplicate that. > > Sorry I missed the conversation about tablespaces. One of the reasons I think > Postgres is so usable is because it does not require the use of tablespace > files. If by tablespace, you mean to declare a directory on a device as a > tablespace, then cool. If you want to create tablespace "files" ala Oracle, you > are heading toward an administration nightmare. Don't get me wrong, the ability > to use a file as a tablespace would be kind of cool, i.e. you can probably use > raw devices, but please to not abandon the way postgres currently works. > > On our Oracle server, we have run out of space on our tablespace files and not > known it was coming. I am the system architect, not the DBA, so I don't have > (nor want) direct control over the oracle database operation. Our newbe DBA did > not make the table correctly, so they did not grow. Alas he was laid off, thus > we were left trying to figure out what was happening. > > Postgres is easier to configure and get right. IMHO that is one of its very > important strengths. It is almost trivial to get a working SQL system up and > running which performs well. > >
В списке pgsql-hackers по дате отправления: