Can someone comment on this?


[ Charset ISO-8859-1 unsupported, converting... ]
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > 
> > > I'm now inclined to introduce a new system relation to store
> > > the physical path name. It could also have table(data)space
> > > information in the (near ?) future. 
> > > It seems better to separate it from pg_class because table(data?)
> > > space may change the concept of table allocation.
> > 
> > Why not just put it in pg_class?
> >
> 
> Not sure,it's only my feeling.
> Comments please,everyone.
> 
> We have taken a practical way which doesn't break file per table
> assumption in this thread and it wouldn't so difficult  to implement.
> In fact Ross has already tried it.
> 
> However there was a discussion about data(table)space for
> months ago and currently a new discussion is there.
> Judging from the previous discussion,I can't expect so much
> that it could get a practical consensus(How many opinions there
> were). We can make a practical step toward future by encapsulating
> the information of table allocation. Separating table alloc info from
> pg_class seems one of the way. 
> There may be more essential things for encapsulation. 
> 
> Comments ?
> 
> Regards.
> 
> Hiroshi Inoue
> Inoue@tpf.co.jp
> 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 9 Jun 2000 13:29:26 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Fix for RENAME
Seems Vadim's new storage manager for 7.2 would be the way to go.

I think he is going to have everything in one file.

[ Charset ISO-8859-1 unsupported, converting... ]
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > 
> > Can someone comment on this?
> >
> 
> It seems to me that we have to reach some consensus in
> order to get a standard transactional control mechanism
> to change the allocation of table files. Probably we would
> have to separate things into 2 parts.
>  
> 1) Where to allocate tables --  we would need some encapsulation
>     like tablespace.  It would be better to be handled differently by
>     each storage manager. Note that tablespace is only an encap-
>     sulation and doesn't necessarily mean that of Oracle.
> 2) Where tables are allocated --  only specific strorage manager
>     knows the meaing and everything would be treated internally.
> 
> Under current (file per table) storage manager,#1 isn't necessarily
> needed for the implementaion of #2 and Ross has already tried it.
> If we could get some consensus on the future direction of 1)2),
> we would be able to apply his implementation.
> 
> Regards.
> 
> Hiroshi Inoue
> Inoue@tpf.co.jp
>  
> > 
> > [ Charset ISO-8859-1 unsupported, converting... ]
> > > > -----Original Message-----
> > > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > > > 
> > > > > I'm now inclined to introduce a new system relation to store
> > > > > the physical path name. It could also have table(data)space
> > > > > information in the (near ?) future. 
> > > > > It seems better to separate it from pg_class because table(data?)
> > > > > space may change the concept of table allocation.
> > > > 
> > > > Why not just put it in pg_class?
> > > >
> > > 
> > > Not sure,it's only my feeling.
> > > Comments please,everyone.
> > > 
> > > We have taken a practical way which doesn't break file per table
> > > assumption in this thread and it wouldn't so difficult  to implement.
> > > In fact Ross has already tried it.
> > > 
> > > However there was a discussion about data(table)space for
> > > months ago and currently a new discussion is there.
> > > Judging from the previous discussion,I can't expect so much
> > > that it could get a practical consensus(How many opinions there
> > > were). We can make a practical step toward future by encapsulating
> > > the information of table allocation. Separating table alloc info from
> > > pg_class seems one of the way. 
> > > There may be more essential things for encapsulation. 
> > > 
> > > Comments ?
> > > 
> > > Regards.
> > > 
> > > Hiroshi Inoue
> > > Inoue@tpf.co.jp
> > > 
> > > 
> > 
> > 
> > -- 
> >   Bruce Momjian                        |  http://www.op.net/~candle
> >   pgman@candle.pha.pa.us               |  (610) 853-3000
> >   +  If your life is a hard drive,     |  830 Blythe Avenue
> >   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> > 
> > 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 11 Jun 2000 23:14:06 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Fix for RENAME
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> 
> Can someone comment on this?
>

It seems to me that we have to reach some consensus in
order to get a standard transactional control mechanism
to change the allocation of table files. Probably we would
have to separate things into 2 parts.
 
1) Where to allocate tables --  we would need some encapsulation
    like tablespace.  It would be better to be handled differently by
    each storage manager. Note that tablespace is only an encap-
    sulation and doesn't necessarily mean that of Oracle.
2) Where tables are allocated --  only specific strorage manager
    knows the meaing and everything would be treated internally.

Under current (file per table) storage manager,#1 isn't necessarily
needed for the implementaion of #2 and Ross has already tried it.
If we could get some consensus on the future direction of 1)2),
we would be able to apply his implementation.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp
 
> 
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > -----Original Message-----
> > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > > 
> > > > I'm now inclined to introduce a new system relation to store
> > > > the physical path name. It could also have table(data)space
> > > > information in the (near ?) future. 
> > > > It seems better to separate it from pg_class because table(data?)
> > > > space may change the concept of table allocation.
> > > 
> > > Why not just put it in pg_class?
> > >
> > 
> > Not sure,it's only my feeling.
> > Comments please,everyone.
> > 
> > We have taken a practical way which doesn't break file per table
> > assumption in this thread and it wouldn't so difficult  to implement.
> > In fact Ross has already tried it.
> > 
> > However there was a discussion about data(table)space for
> > months ago and currently a new discussion is there.
> > Judging from the previous discussion,I can't expect so much
> > that it could get a practical consensus(How many opinions there
> > were). We can make a practical step toward future by encapsulating
> > the information of table allocation. Separating table alloc info from
> > pg_class seems one of the way. 
> > There may be more essential things for encapsulation. 
> > 
> > Comments ?
> > 
> > Regards.
> > 
> > Hiroshi Inoue
> > Inoue@tpf.co.jp
> > 
> > 
> 
> 
> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> 

Mon, 12 Jun 2000 12:14:08 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Fix for RENAME
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> 
> Seems Vadim's new storage manager for 7.2 would be the way to go.
> 
> I think he is going to have everything in one file.
>

Probably Vadim would have to change something around storage
manager before 7.1 in his WAL implementation. So what should/
could we do for 7.1 ? If Vadim would do/has done everything,it
should be clearly mentioned. Otherwise other people would waste
their time.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp 

Thu, 15 Jun 2000 08:56:02 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Fix for RENAME