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