[GENERAL] Config for fast huge cascaded updates

Hi folks We're doing a large migration on our site which involves changing most of the primary key values. We've noticed this is a *very* slow process. Firstly we've set up all the foreign keys to use `on update cascade`. Then we essentially do this on every table: UPDATE TABLE users SET id = id

Re: [GENERAL] Config for fast huge cascaded updates

Thanks everyone. Sorry for the late reply. Do you have indexes on all the referencing columns? I had thought so, but it turns out no, and this appears to be the main cause of the slowness. After adding a couple of extra indexes in the bigger tables, things are going much more smoothly. write

[GENERAL] pg_stats.avg_width differs by a factor of 4 on different machines

ave identical data. Note that 81803 is almost exactly 4x20450, though I don't know what significance this has. x64/i386 makes no difference. I couldn't find anything in the 8.3 release notes that looked relevant. Any help appreciated. Regards Craig de Stigter -- Koordinates Ltd PO Box 1604,

Re: [GENERAL] pg_stats.avg_width differs by a factor of 4 on different machines

9, Tom Lane wrote: > Craig de Stigter writes: >> We are using the PostgreSQL pg_stats view to estimate file sizes for some >> geodata exports. However, the following query gives us totally different >> results on different servers: > >> select avg_width from pg_

[GENERAL] dump & restore to different schema

red in the dump. How can I get around this? I would prefer not to use s/^SET search_path.*$/SET search_path TO untrusted_schema/g if I can avoid it ;) Thanks Craig de Stigter -- Koordinates Ltd PO Box 1604, Shortland St, Auckland, New Zealand Phone +64-9-966 0433 Fax +64-9-969 004

[GENERAL] Corrupt indices on already-dropped table (could not open relation with OID ...)

to try the fix mentioned at the following URL since it involves deleting things from system tables: http://javadave.blogspot.com/2005/06/could-not-open-relation-in-postgresql.html Any suggestions for a nicer approach? Or can someone who knows tell me if its okay to follow the instructions at

Re: [GENERAL] Corrupt indices on already-dropped table (could not open relation with OID ...)

opped the table and tried to recreate the table we noticed the indices were still there. I don't see a reason to beterribly concerned about the consistency of the > entries about this index. The only issue is that we do want to be able to create that table again... Thanks a bunch Craig