Mon Jun 25 09:31:16 PDT 2007
- Previous message: [Slony1-hackers] Re: [Slony1-commit] slony1-engine/tools slony1_dump.sh
- Next message: [Slony1-hackers] xxid.v83.sql installation in V2.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I was taking a look at the Skytools message queueing system, which consciously borrows some functionality from Slony-I, and noticed a technique there that appeared attractive. They set up a SRF that returns the list of tables that need to be vacuumed by their cleanup thread. That seemed an attractive change to make for Slony-I, too, in the 2.0 branch (e.g. - HEAD) It turns out to be QUITE an intrusive change to Slony-I in view of the fairly large amount of code that has been assortedly added to the cleanup thread to: 1. Detect if we're on 8.1 or higher (to see if autovac exists) This can get thrown away; CVS HEAD is only compatible with 8.3+, so we can certainly assume that autovacuum is available. 2. Detect if autovac is actually running Which generates quite a bunch of C code... I'll shift this into the stored function(s); that will have two salutory effects: i. The pl/pgsql code is a lot simpler than the C ii. The pl/pgsql will detect online changes dynamically; I'm less sure that the C version could detect such 3. The stored function that gets called will do rather a lot more in its logic, and make the C logic nearly disappear. - It will encode, more dynamically (e.g. - it can easily be upgraded online without needing a recompile) the list of tables - It doesn't require any special quoting functions to generate compatible namespace names because it knows the 2 namespaces involved (@NAMESPACE@, pg_catalog) - For each table, we'll submit a query that checks to see if: - autovac is running, and - that table is being handled by autovac - If the table is being handled by autovac, we won't bother returning it as part of the set - If it isn't then we need to vacuum it, and can provide fully qualified table and namespace names In effect, the C code merely needs to query the SRF, and run VACUUM / VACUUM ANALYZE on each table that the SRF returns. It looks like we'll lose quite a bit of C code if I make this change, and can simplify the cleanup thread quite a bit. Seems like a good thing...
- Previous message: [Slony1-hackers] Re: [Slony1-commit] slony1-engine/tools slony1_dump.sh
- Next message: [Slony1-hackers] xxid.v83.sql installation in V2.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-hackers mailing list