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 to 256MB. [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 debate. 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]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
