oid2name and relfilenode

Started by Bruce Momjianover 23 years ago8 messageshackers
Jump to latest
#1Bruce Momjian
bruce@momjian.us

Now that we are changing relfilenode in 7.3, I think we need to rename
oid2name to relfilenode2name, and perhaps move it into the main tree.

TODO item added:

Rename oid2name to relfilenode2name and install by default

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#2Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#1)
Re: oid2name and relfilenode

Bruce Momjian wrote:

Now that we are changing relfilenode in 7.3, I think we need to rename
oid2name to relfilenode2name, and perhaps move it into the main tree.

TODO item added:

Rename oid2name to relfilenode2name and install by default

Actually, to be accurate, I think databases are stored based on their
oid and tables/indexes are stored based on their relfilenode. That is
pretty confusing. Do we still do the renaming?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#3Justin Clift
justin@postgresql.org
In reply to: Bruce Momjian (#2)
Re: oid2name and relfilenode

Bruce Momjian wrote:

Bruce Momjian wrote:

Now that we are changing relfilenode in 7.3, I think we need to rename
oid2name to relfilenode2name, and perhaps move it into the main tree.

TODO item added:

Rename oid2name to relfilenode2name and install by default

Should it be renamed to pg_<something> for namespace consistency?

:-)

Regards and best wishes,

Justin Clift

Actually, to be accurate, I think databases are stored based on their
oid and tables/indexes are stored based on their relfilenode. That is
pretty confusing. Do we still do the renaming?

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 359-1001
+  If your life is a hard drive,     |  13 Roberts Road
+  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

#4Bruce Momjian
bruce@momjian.us
In reply to: Justin Clift (#3)
Re: oid2name and relfilenode

Justin Clift wrote:

Bruce Momjian wrote:

Bruce Momjian wrote:

Now that we are changing relfilenode in 7.3, I think we need to rename
oid2name to relfilenode2name, and perhaps move it into the main tree.

TODO item added:

Rename oid2name to relfilenode2name and install by default

Should it be renamed to pg_<something> for namespace consistency?

Good question. We usually add the pg_ for stuff that could be
confusing, like pg_dump or pg_restore. For things like vacuumdb and
dropdb, we don't. We probably should have pg_ on createuser, but
historically we haven't.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#5Peter Eisentraut
peter_e@gmx.net
In reply to: Bruce Momjian (#2)
Re: oid2name and relfilenode

Bruce Momjian writes:

Rename oid2name to relfilenode2name and install by default

Actually, to be accurate, I think databases are stored based on their
oid and tables/indexes are stored based on their relfilenode. That is
pretty confusing. Do we still do the renaming?

I don't think we should do either of these. Instead of giving people
tools to dig around in the internals, let's give them tools to get the
information they really want. Not sure what that is though.

--
Peter Eisentraut peter_e@gmx.net

#6Bruce Momjian
bruce@momjian.us
In reply to: Peter Eisentraut (#5)
Re: oid2name and relfilenode

Peter Eisentraut wrote:

Bruce Momjian writes:

Rename oid2name to relfilenode2name and install by default

Actually, to be accurate, I think databases are stored based on their
oid and tables/indexes are stored based on their relfilenode. That is
pretty confusing. Do we still do the renaming?

I don't think we should do either of these. Instead of giving people
tools to dig around in the internals, let's give them tools to get the
information they really want. Not sure what that is though.

That's the problem. People sometimes need to access those files from
the file system level. There are just too many variations of why they
need that I don't think there is any way to anticipate them. If someone
comes up with a better idea, I am all ears, but seeing as nothing better
has appeared since it was first written, I think we need to move forward.

I will add these items to the TODO list, unless someone else votes. I
think they are too important to have in /contrib (and we moved
pg_resetxlog/pg_controldata from /contrib in 7.3) and I think
relfilenode is better than OID so people start using that rather than
OID for filename mapping.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#6)
Re: oid2name and relfilenode

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I will add these items to the TODO list, unless someone else votes.

I was not thrilled with the idea of moving oid2name out of contrib
either, but kept silent to see if someone else would complain first ...

Basically I think that oid2name is a hacker's tool and not something
users or DBAs really want as-is --- which I guess is another way of
stating Peter's gripe that what it produces is not what the users want
to know. The actual useful guts of it are nothing more than
SELECT oid, datname FROM pg_database;
SELECT relfilenode, relname FROM pg_class;
which does not seem significant enough to justify the packaging and
documentation overhead of having another command-line tool.

The only actual use-case I've seen for it so far is as a vehicle for
computing actual database sizes on-disk; which would be better served
by a tool that did the whole job. What other uses do people have for
oid2name?

regards, tom lane

#8Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#7)
Re: oid2name and relfilenode

OK, removed from TODO. I figured it was as useful as pg_controldata but
can see what you say that those give information that you can't get any
other way, while oid2name info can be gotten another way. You can look
at the oid2name README for examples of its usage.

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

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I will add these items to the TODO list, unless someone else votes.

I was not thrilled with the idea of moving oid2name out of contrib
either, but kept silent to see if someone else would complain first ...

Basically I think that oid2name is a hacker's tool and not something
users or DBAs really want as-is --- which I guess is another way of
stating Peter's gripe that what it produces is not what the users want
to know. The actual useful guts of it are nothing more than
SELECT oid, datname FROM pg_database;
SELECT relfilenode, relname FROM pg_class;
which does not seem significant enough to justify the packaging and
documentation overhead of having another command-line tool.

The only actual use-case I've seen for it so far is as a vehicle for
computing actual database sizes on-disk; which would be better served
by a tool that did the whole job. What other uses do people have for
oid2name?

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073