From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Assigning fixed OIDs to system catalogs and indexes |
Date: | 2005-04-12 21:19:01 |
Message-ID: | 29990.1113340741@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While thinking about the use of hand-assigned OIDs for pg_proc and
pg_operator, it occurred to me to wonder why we don't have hand-assigned
OIDs for all system catalogs and indexes. Currently, most of the time
that the C code wants to reference a specific catalog or index, it has
to reference it by name. If we had fixed OIDs for all the catalogs and
indexes known to the C code, we could get rid of heap_openr,
index_openr, and the index-by-name maintained inside the relcache,
because *all* such accesses would go by OID. I don't have hard numbers
to prove it, but I think that the aggregate overhead of doing string
instead of integer comparisons during those lookups has to be
nontrivial. There are other annoyances such as having to use
get_system_catalog_relid() in many places where a constant would be nice
to have.
The code wouldn't get any less readable -- we'd just be replacing macros
that expand to strings with ones that expand to numbers.
Thoughts? Anyone have an argument why we should not do this?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-04-13 01:47:55 | Re: Assigning fixed OIDs to system catalogs and indexes |
Previous Message | Tom Lane | 2005-04-12 21:09:46 | Simplifying bootstrap OID assignment |