RE: Big 7.1 open items - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: Big 7.1 open items
Date
Msg-id 000201bfdbd9$b1985580$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: Big 7.1 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Big 7.1 open items
List 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 by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: Big 7.1 open items
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: Big 7.1 open items