From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: WIP: getting rid of the pg_database flat file |
Date: | 2009-08-12 13:35:48 |
Message-ID: | 20090812133548.GC5721@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-08-12 13:38:30 | Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) |
Previous Message | Tom Lane | 2009-08-12 13:35:30 | Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) |