RE: Big 7.1 open items

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: Big 7.1 open items
Дата
Msg-id 000201bfdbd9$b1985580$2801007e@tpf.co.jp
обсуждение исходный текст
Ответ на Re: Big 7.1 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Big 7.1 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> No argument from me ;-).  I've been looking for compromise positions
> but I still think that pure numeric filenames are the cleanest solution.
>
> There's something else that should be taken into account: for WAL, the
> log will need to record the table file that each insert/delete/update
> operation affects.  To do that with the smgr-token-is-a-pathname
> approach I was suggesting yesterday, I think you have to record the
> database name and pathname in each WAL log entry.  That's 64 bytes/log
> entry which is a *lot*.  If we bit the bullet and restricted ourselves
> to numeric filenames then the log would need just four numeric values:
>     database OID
>     tablespace OID

I strongly object to keep tablespace OID for smgr file reference token
though we have to keep it for another purpose of cource. I've mentioned
many times tablespace(where to store) info should be distinguished from
*where it is stored* info. Generally tablespace isn't sufficiently
restrictive
for this purpose. e.g. there was an idea about round-robin. e.g. Oracle's
tablespace could have pluaral files... etc.
IMHO,it is misleading to use tablespace OID as (a part of) reference token.

>     relation OID
>     relation version number
> (this set of 4 values would also be an smgr file reference token).
> 16 bytes/log entry looks much better than 64.
>

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



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

Предыдущее
От: "Mikheev, Vadim"
Дата:
Сообщение: RE: Big 7.1 open items
Следующее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: Big 7.1 open items