Re: WIP: getting rid of the pg_database flat file

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: WIP: getting rid of the pg_database flat file
Дата
Msg-id 20090812133548.GC5721@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: WIP: getting rid of the pg_database flat file  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: WIP: getting rid of the pg_database flat file  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:

> What was sort of in the back of my mind was to have every n'th AV worker
> examine pg_database and report back to the launcher (probably through
> shared memory) with an indication of the next few databases that should
> be vacuumed and when.  Not sure how inefficient that might be though.

Hmm, probably we could do this.  The one open question is how would it
know what to do the first time around when there's no information set up
yet, so it cannot start a worker.  I guess we could hardcode to start a
worker in database with Id 1, but that doesn't seem like an improvement.

> Is there a real downside to promoting the launcher to be a
> pseudo-backend?

Aside from the fact that we don't have any pseudo-backend yet, I don't
see any ...

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)