| From: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Assigning fixed OIDs to system catalogs and indexes |
| Date: | 2005-04-13 01:47:55 |
| Message-ID: | d3htrr$o8k$1@news.hub.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes
> 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.
So some changing-oid operations like vacuum full, reindex, etc will not
affect these system catalogs?
Regards,
Qingqing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2005-04-13 01:54:28 | Re: Assigning fixed OIDs to system catalogs and indexes |
| Previous Message | Tom Lane | 2005-04-12 21:19:01 | Assigning fixed OIDs to system catalogs and indexes |