Re: Relation locking and relcache load (was Re: Going for "all green" buildfarm results)
От | Stephen Frost |
---|---|
Тема | Re: Relation locking and relcache load (was Re: Going for "all green" buildfarm results) |
Дата | |
Msg-id | 20060731141846.GZ20016@kenobi.snowman.net обсуждение исходный текст |
Ответ на | Re: Relation locking and relcache load (was Re: Going for "all green" buildfarm results) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Relation locking and relcache load (was Re: Going for "all green" buildfarm results)
|
Список | pgsql-hackers |
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > I think the best solution for this might be to put the responsibility > for creating system catalogs' toast tables into the bootstrap phase > instead of making initdb do it afterwards. This would be a Good Thing > anyway since currently we are incapable of dealing with bootstrap-time > insertions of values large enough to need toasting. I'm imagining > adding macros to the include/catalog/*.h files along the lines of Would this make it much more difficult to support user-defined indexes on system catalogs? It looks like we don't support that at the moment but as we see larger Postgres installations it seems likely we'll need to. I don't really consider myself a very heavy Postgres user but I've got databases w/ > 30k entries in pg_class and near 300k in pg_attribute... Those aren't shared but it sounds like you were talking about all of them above anyway. Thanks, Stephen
В списке pgsql-hackers по дате отправления: