postgresql наследование таблиц

ооо, интересно такое есть в mysql?

в mysql много чего нет постгрисового. сейчас начал только с постгрисом возиться - дык рулез какой-то по сравнению с мускулем :)

правда некоторых вещей в нем нет INSERT ON DUPLICATE KEY например. можно создать правило, будет такой инсерт эмулировать, но не будет справляться с дублями внутри самого такого инсерта. а так все остальное - руль. например структуры и массивы (в т.ч. структур) в виде столбиков, процедуры на перле, возможность при INSERT сразу и обратно получить вставленные данные итп итд

кроме того я тут сваял тест: у меня вот эти самые устройства копят данные в БД. на тестовом хосте (десктоп слабая машинка) mysql на innodb делает примерно 200 инсертов в секунду. postgresql (при том что я в его админинге, в отличие от mysql ни бум бум еще, просто поставил) - делает 500. мне прямо это все подозрительным кажется. не бывает столько халявы-то зараз. где-то видимо расплатиться все равно придется :)

Конечно можно. Заведи ещё одно общее поле с типом устройства которое одновременно будет неявно указывать и на таблицу.

ну это я сразу и сделал. просто думал может можно от этого поля избавиться как-то? БД ведь во время выборки эту информацию имеет, может можно ее как-то явно заполучить?

Попробуй спроси на sql.ru, но афаик иначе нельзя.

http://www.postgresql.org/docs/9.0/static/ddl-inherit.html

In some cases you might wish to know which table a particular row originated from. There is a system column called tableoid in each table which can tell you the originating table:

SELECT c.tableoid, c.name, c.altitude
FROM cities c
WHERE c.altitude > 500;

 tableoid |   name    | altitude
----------+-----------+----------
   139793 | Las Vegas |     2174
   139793 | Mariposa  |     1953
   139798 | Madison   |      845

SELECT p.relname, c.name, c.altitude
FROM cities c, pg_class p
WHERE c.altitude > 500 AND c.tableoid = p.oid;

 relname  |   name    | altitude
----------+-----------+----------
 cities   | Las Vegas |     2174
 cities   | Mariposa  |     1953
 capitals | Madison   |      845

Охренеть, спасибо.

спасибо.

чую можно по ссылкам в FK но пока на практике не применял.

а еще вопрос: если мы в родительскую таблицу никогда не пишем, а только читаем из нее, то созданные в родительской таблице индексы имеют чисто декоративное значение, даже при выборках из этой таблицы. я правильно понимаю ситуацию?

> где-то видимо расплатиться все равно придется
не знаю, как там сейчас, но раньше расплачиваться приходилось при первом же vacuum :)
Причём никакой autovacuum не помогал.

Недопол. Что значит — не пишем, а только читаем? Индекс при записи — вообще исключительно головная боль, кою терпят исключительно из-за выигрыша при чтении. Или ты о том, что родительская таблица пустая? Тогда от индексов толку, скажем так, ровно столько же, сколько и от полей оной таблицы — они нужны исключительно для планирования запросов...

Представь себе: через какое-то время таблицы разрастаются и ты принимаешь решение сегментировать логи устройств по времени. Сразу эта схема с различением по таблице теряет свою привлекательность, имхо...

Что значит — не пишем, а только читаем?

поскольку родительская таблица содержит только метаданные (данные проходящие сквозняком сквозь все таблицы), то запись в нее смысла не имеет.

а вот чтение имеет (запрос вида: «а в каких у нас таблицах остались необработанные данные?»)

и, насколько я понимаю, запрос из родительской таблицы он неявно преобразует в запрос из таблицы 1 объединенный с запросом из таблицы 2 и так далее

то есть индексы по родительской таблицы не нужны, если она не содержит ни одной записи?

Ни индексы, ни внешние ключи, ни первичные ключы, ни констрайнты не имеют никакого значения на родительской таблице если вы не храните там данные.

SELECT * from parent аналогичен

select * from parent
union all
select * from child_1
union all
select * from child_2
union all
...
union all
select * from child_n

PS: посмотрите еще про constraint exclusion - незаменимая вешь для таблиц > 10Gb

Таки да. Перечёл доки. Не наследуются. Только check и not bull constraints. Действительно, индексы смысла не имеют.