Re: [HACKERS] [hackers]development suggestion needed
От | Don Baccus |
---|---|
Тема | Re: [HACKERS] [hackers]development suggestion needed |
Дата | |
Msg-id | 3.0.1.32.20000113205003.01083d50@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [hackers]development suggestion needed (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
At 10:18 PM 1/13/00 -0500, Bruce Momjian wrote: >> Oracle tables and indices within a single tablespace all live in >> one file (if you're using filesystem rather than raw I/O), so >> they also provide features which allow you to specify how big >> a chunk to allocate per extent (Oracle pre-allocates to avoid >> running out of disk space while you're running except in ways >> that you control, and in hopes of getting contiguous chunks of >> disk storage because they hope you're using previously empty >> disks used only for Oracle). > >And with data and index in the same file, you can't split them across >spindles. Which is why folks define more than one tablespace, eh? Something you can't do in PG... Perhaps I didn't make it clear that you can define as many tablespaces as you want? And freely assign any table or index to any tablespace you want? Given my statement above, it is clear you can: 1. Coalesce indices and tables into a single tablespace (the default) if you only define one (again, more or less how Oracledefaults, though I sorta forget because I'm not an Oracle stud and no one in their right mind allows Oracle to setdefaults, because they're always wrong) -or- 2. At the other extreme, you can define as many tablespaces as you have tables and indices, and each can live in theirown separate tablespace (i.e. spindle, if that is what you want to do). -or- 3. Set yourself up at any point between either extreme, according to your own needs. I don't think it's that difficult to understand, is it? - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: