Re: Tables on multiple disk drives
От | Craig Thomas |
---|---|
Тема | Re: Tables on multiple disk drives |
Дата | |
Msg-id | 64789.4.5.9.170.1077039338.squirrel@www.osdl.org обсуждение исходный текст |
Ответ на | Re: Tables on multiple disk drives ("scott.marlowe" <scott.marlowe@ihs.com>) |
Ответы |
Re: Tables on multiple disk drives
|
Список | pgsql-performance |
> On Tue, 17 Feb 2004, Konstantin Tokar wrote: > >> Hi! >> Does PostgreSQL allow to create tables and indices of a single >> database on multiple disk drives with a purpose of increase >> performance as Oracle database does? If a symbolic reference is the >> only method then the next question is: how can it be determined what >> file is referred to what table and index? > > You're life will be simpler, and your setup will be faster without > having to muck about with it, if you just buy a good RAID controller > with battery backed cache. LSI/Megaraid and Adaptec both make > serviceable controllers for reasonable prices, and as you add drives, > the speed just goes up, no muddling around with sym links. This works to a limited extent. For very large databases, maximum throughput of I/O is the paramount factor for database performance. With raid controllers, your LUN is still limited to a small number of disks. PostgreSQL can only write on a file system, but Oracle, SAP DB, DB2, etc can write directly to disk (raw I/O). With large databases it is advantageous to spread a table across 100's of disks, if the table is quite large. I don't know of any manufacturer that creates a 100 disk raid array yet. Some of the problem can be addressed by using a volume manager (such as LVM in Linux, or Veritas on Unix-like systems). This allows one to create a volume using partitions from many disks. One can then create a file system and mount it on the volume. However, to get the best performance, Raw I/O capability is the best way to go. > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
В списке pgsql-performance по дате отправления: