| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: DROP INHERITS |
| Date: | 2006-06-07 05:11:08 |
| Message-ID: | 87ejy17doz.fsf@stark.xeocode.com |
| 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:
> > I suppose it makes more sense to optimize this on the basis of what's used in
> > the planner and executor rather than ALTER TABLE commands though.
>
> No, definitely not. Syscaches only exist to support hard-wired lookups
> in the backend C code. Indexes on system catalogs are of interest to
> the planner, but not syscaches. (So it is legitimate to have indexes
> with no associated syscache. The other way is not possible, though,
> because the syscache mechanism depends upon having a matching index.)
I imagine the planner and/or executor have to execute hard-wired lookups in C
code all day long to check for children of tables before they can execute
queries on those tables. I meant that the performance of those lookups was
undoubtedly more critical than the performance of DDL.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ITAGAKI Takahiro | 2006-06-07 06:09:31 | Re: fillfactor using WITH syntax |
| Previous Message | Koichi Suzuki | 2006-06-07 04:15:56 | Re: How to avoid transaction ID wrap |