That's awesome, thanks! Yeah, I doubt I'll do that to our production database, but maybe I'll try it on a copy sometime down the line. Adjusting the cost for pg_table_is_visible is working well enough so far.
Cody Cutrer On Wed, Mar 21, 2012 at 12:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Cody Cutrer <c...@instructure.com> writes: >> On Tue, Mar 20, 2012 at 6:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> There's not really support for adding indexes to system catalogs >>> on-the-fly. I think it would work (barring concurrency issues) >>> for most catalogs, but pg_class has special limitations due to >>> the "relmapping" infrastructure. It's not something I'd particularly >>> care to try on a production database. > > BTW, I experimented with that a little bit and found that the relmapper > is not really the stumbling block, at least not after applying this > one-line patch: > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f70f095c9096d5e2689e8d79172b37b57a84e51b > > It seemed to work for me to do this: > > stop postmaster > start a standalone backend with -c allow_system_table_mods=1 > create index pg_class_relnamespace_index on pg_class(relnamespace); > stop standalone backend, restart postmaster > > There are a lot of gotchas here, notably that the session in which you > create the index won't know it's there (so in this case, a reindex on > pg_class would likely be advisable afterwards). I still think you'd be > nuts to try it on a production database, but ... > > regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
