Status of index location patch

Just wondering what is the status of this patch. Is seems from comments
that people like the idea. I have also looked in the archives for other
people looking for this kind of feature and have found alot of interest.

If you think it is a good idea for 7.2, let me know what needs to be
changed and I will work on it this weekend.

Just change index' dir naming as was already discussed.

Vadim

On Saturday 15 September 2001 03:03, Jim Buttafuoco wrote:

Just wondering what is the status of this patch. Is seems from comments
that people like the idea. I have also looked in the archives for other
people looking for this kind of feature and have found alot of interest.

Can we have a web based tracking system for patch tracking? I am ready to
volunteer. I may be of some help.

Shridhar

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Vadim,

I guess I am still confused...

In dbcommands.c resolve_alt_dbpath() takes the db oid as a argument.
This number is used to "find" the directory where the data files live.
All the patch does is put the indexes into a "db oid"_index directory
instead of "db oid"

This is for tables snprintf(ret, len, "%s/base/%u", prefix, dboid);
This is for indexes snprintf(ret, len, "%s/base/%u_index", prefix,
dboid);

And in catalog.c
tables: sprintf(path, "%s/base/%u/%u", DataDir, rnode.tblNode,
rnode.relNode);
indexes: sprintf(path, "%s/base/%u_index/%u", DataDir,
rnode.tblNode,rnode.relNode);

Can you explain how I would get the tblNode for an existing database
index files if it doesn't have the same OID as the database entry in
pg_databases.

Jim

Just wondering what is the status of this patch. Is seems from

comments

that people like the idea. I have also looked in the archives for

other

people looking for this kind of feature and have found alot of

interest.

Can you explain how I would get the tblNode for an existing database
index files if it doesn't have the same OID as the database entry in
pg_databases.

Well, keeping in mind future tablespace implementation I would
add tblNode to pg_class and in pg_databases I'd have
defaultTblNode and indexTblNode.
If it's too late to do for 7.2 then let's wait till 7.3.

Vadim

Yes that is exactly what I am going to do for 7.3 (had trouble adding
tblNode to pg_class so I stopped for now...)

Can you explain how I would get the tblNode for an existing database
index files if it doesn't have the same OID as the database entry

in

pg_databases.

Well, keeping in mind future tablespace implementation I would
add tblNode to pg_class and in pg_databases I'd have
defaultTblNode and indexTblNode.
If it's too late to do for 7.2 then let's wait till 7.3.

Vadim

---------------------------(end of

broadcast)---------------------------

TIP 1: subscribe and unsubscribe commands go to

majordomo@postgresql.org

Jim, do you have an updated patch that you would like applied for 7.3?

---------------------------------------------------------------------------

Jim Buttafuoco wrote:

Vadim,

I guess I am still confused...

In dbcommands.c resolve_alt_dbpath() takes the db oid as a argument.
This number is used to "find" the directory where the data files live.
All the patch does is put the indexes into a "db oid"_index directory
instead of "db oid"

This is for tables snprintf(ret, len, "%s/base/%u", prefix, dboid);
This is for indexes snprintf(ret, len, "%s/base/%u_index", prefix,
dboid);

And in catalog.c
tables: sprintf(path, "%s/base/%u/%u", DataDir, rnode.tblNode,
rnode.relNode);
indexes: sprintf(path, "%s/base/%u_index/%u", DataDir,
rnode.tblNode,rnode.relNode);

Can you explain how I would get the tblNode for an existing database
index files if it doesn't have the same OID as the database entry in
pg_databases.

Jim

Just wondering what is the status of this patch. Is seems from

comments

that people like the idea. I have also looked in the archives for

other

people looking for this kind of feature and have found alot of

interest.

If you think it is a good idea for 7.2, let me know what needs to be
changed and I will work on it this weekend.

Just change index' dir naming as was already discussed.

Vadim

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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,

I stopped all work on this since people seemed confused about the
tablespace/location words. I don't think enough of the "core" team likes
this idea. Am I wrong here? Did I explain the patch good enough?

Please let me know, I still am planning on doing it for internal use. I
would prefer that it was a standard feature. If you think I should still
pursue this, let me know what I need to do to get it off the ground.

Thanks for your help
Jim

Jim Buttafuoco wrote:

Bruce,

I stopped all work on this since people seemed confused about the
tablespace/location words. I don't think enough of the "core" team likes
this idea. Am I wrong here? Did I explain the patch good enough?

Please let me know, I still am planning on doing it for internal use. I
would prefer that it was a standard feature. If you think I should still
pursue this, let me know what I need to do to get it off the ground.

I think ideally we need to work in the direction outlined in the TODO
list link for tablespaces. We clearly need this functionality, but I
think there is a perception we need to do it right the first time. I
don't see your work as that far away from where we want to be so I
encourage you to read the link next to tablespaces and see what parts
you like and what parts you don't.

The usual steps are to outline the functionality you want to add, then
we can discuss implementation. It is a feature we very badly need.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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