Re: smgr.c and smgrtype.c

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: smgr.c and smgrtype.c
Дата
Msg-id 12770.1098170876@sss.pgh.pa.us
обсуждение исходный текст
Ответ на smgr.c and smgrtype.c  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
Ответы Re: smgr.c and smgrtype.c  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
Список pgsql-hackers
Satoshi Nagayasu <nagayasus@nttdata.co.jp> writes:
> I'm trying to modify the storage manager now.

Um ... why?

There is no doubt that the current smgr interface leaves a lot to be
desired, but the reason that it's in such sad shape is that there is
absolutely no modern-day use for an API at that particular level of
abstraction.  The stuff that the Berkeley boys and girls envisioned
doing here has all migrated down into the kernel, if not clear down
into the hardware (think RAID controller).  Most of the stuff that
people would now like to have an API separation for is at much higher
levels of abstraction.  For example, the smgr API doesn't even know what
a tuple or an index *is*, much less have the potential to modify lookup
or locking or replication semantics.

If anyone had wanted to add a new storage manager in the last fifteen
years, we'd doubtless have tried to clean this up some, but no one has
and I'm not really expecting anyone to try in the next fifteen...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: 7.4 changes
Следующее
От: Satoshi Nagayasu
Дата:
Сообщение: Re: smgr.c and smgrtype.c