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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Relation locking and relcache load (was Re: Going for "all green" buildfarm results)
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: Connection limit and Superuser