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
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
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
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
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
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_
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,
