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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Two weeks to feature freeze
Следующее
От: "Andrew Dunstan"
Дата:
Сообщение: Re: [GENERAL] Physical Database Configuration