Re: Status of index location patch

Lists: pgsql-hackers
From: "Jim Buttafuoco" <jim(at)buttafuoco(dot)net>
To: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>, <jim(at)buttafuoco(dot)net>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Status of index location patch
Date: 2001-09-15 17:54:39
Message-ID: 200109151754.f8FHsdB08189@dual.buttafuoco.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
>
>


From: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
To: <jim(at)buttafuoco(dot)net>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Status of index location patch
Date: 2001-09-15 19:40:51
Message-ID: 004501c13e1e$54b31cd0$4e79583f@home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: jim(at)buttafuoco(dot)net
Cc: Vadim Mikheev <vmikheev(at)sectorbase(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Status of index location patch
Date: 2002-02-22 18:05:50
Message-ID: 200202221805.g1MI5o429319@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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(at)postgresql(dot)org)
>

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


From: "Jim Buttafuoco" <jim(at)buttafuoco(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, jim(at)buttafuoco(dot)net
Cc: Vadim Mikheev <vmikheev(at)sectorbase(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Status of index location patch
Date: 2002-03-03 20:34:36
Message-ID: 20020303153436.M48726@buttafuoco.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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, 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(at)postgresql(dot)org)
> >
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026


From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: jim(at)buttafuoco(dot)net
Cc: Vadim Mikheev <vmikheev(at)sectorbase(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Status of index location patch
Date: 2002-03-03 20:46:54
Message-ID: 200203032046.g23KktC25812@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026