Nevermind, I think a backup was getting in the way.  urg.

On Sat, Dec 19, 2009 at 11:48 PM, Scott Marlowe <scott.marlowe at gmail.com> wrote:
> I'm trying to get some work done tonight, running slony 1.2.13 (will
> gladly update if this issue has been addressed) and during an
> operation:
>
> select "_slony_www".storeSet(203, 'set to alter tables');
>
> it is scanning every single attribute of every single table in my
> database, whether it is under replication or not.  This command above
> is generating sql like this:
>
> SELECT a.attnum, a.attname, a.atttypmod, a.attstattarget,
> a.attstorage, t.typstorage, a.attnotnull, a.atthasdef, a.attisdropped,
> a.attislocal, pg_catalog.format_type(t.oid,a.atttypmod) as atttypname
> from pg_catalog.pg_attribute a left join pg_catalog.pg_type t on
> a.atttypid = t.oid where a.attrelid = '78818327'::pg_catalog.oid and
> a.attnum > 0::pg_catalog.int2 order by a.attrelid, a.attnum
>
> If I go look in pg_class for the relfilenode that matches, it's in a
> whole other schema that's not involved in replication at all.  Each
> query is only taking a few milliseconds.  But with 40k or more
> relations in the db, and it seems like a handful of 1 to 5 millisecond
> queries for each one, slony is simply taking hours to do something
> simple, and there's NO REASON for it to be looking at these tables in
> other schemas that are not related.
>



-- 
When fascism comes to America, it will be intolerance sold as diversity.