I recalled seeing a thread on -HACKERS about some major improvements to the speed of
adding an FK to an existing table in 7.4. Naturally I was curious and decided to give
it a whirl. My findings are not too good. In fact, they are bad.
Could it be this patch never made it in?
Anyway, here's the info.
Machine: Linux 2.4.18 [stock rh8], p3 500, 512mb, 4x18GB scsi raid 0
Two tables: members and watchedmembers with 1045720 and 829994 rows respectivly.
freshly vacuum analyze'd for each PG:
7.4b4, 10k shared buff, 256mb effective cache: 485706ms
7.3.4 [same settings]: 412304.76 ms
Now the odd thing during that operation was that the machine was about oh, 50-70%
_idle_ during the whole time.
Then I started thinking more about it and realized hearing if you bump sort_mem up
ridiculously high during a foreign key add it helps. So I did. Bumped it up
[again, vacuum analyze'd each beforehand]
7.3.4: 328912ms [cpu pegged]
7.4b4: 298383ms [cpu pegged]
Quite an improvement I'd say.
Perhaps we should make note of this somewhere? Performance guide? Docs?
And this leads to the place we'd get a huge benefit: Restoring backups.. If there were
some way to bump up sort_mem while doing the restore.. things would be much more
pleasant. [Although, even better would be to disable FK stuff while restoring a backup
and assume the backup is "sane"] How we'd go about doing that is the subject of much
Perhaps add the functionality to pg_restore? ie, pg_restore -s 256MB mybackup.db?
It would just end up issuing a set sort_mem=256000..
What do you guys think?
Jeff Trout <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])