Re: [GENERAL] Physical Database Configuration
От | Jeff |
---|---|
Тема | Re: [GENERAL] Physical Database Configuration |
Дата | |
Msg-id | Pine.BSF.4.44.0306251516270.30536-100000@torgo.978.org обсуждение исходный текст |
Ответ на | Re: [GENERAL] Physical Database Configuration (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, 25 Jun 2003, Tom Lane wrote: > Has anyone looked at the syntaxes used by other databases to control > tablespaces (Oracle, DB2, etc)? I have no strong desire to slavishly > follow Oracle, but it would be a shame to miss out on any good ideas. > Informix is pretty bad. First, you use an external app to create the tablespace (known as a dbspace to informix). Lets call the new one 'newspace'. (the syntax is onspaces -c -d newspace -p /path/to/space -s size_in_kb -o offset_in_file I'll cry if we have something liek that in pg) then to 'use' the space: create table|index ... in newspace There's a bizzare syntax for copying a table from one space to another, but it is mostly useless since it runs in a transaction and if you have a big table.. well you get the idea. Where it gets more interesting is table fragments. Informix is able to fragment a table based on a few different criteria. Each fragment goes in a separate dbspace and the idea is the planner is smart enough to realize that it can parellelize seq scans and various other IO operations... but given the nature of postgres I don't think we could build something like that... (for the record, the fragment types are round robin and expression. You can fragment based on a limited-edition where clause.. ) -- Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/ http://www.stuarthamm.net/
В списке pgsql-hackers по дате отправления: