I recalled seeing a thread on -HACKERS about some major improvements to the speed of adding an FK to an existing table
in7.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
keyadd 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
whiledoing the restore.. things would be much more pleasant. [Although, even better would be to disable FK stuff while
restoringa 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 <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
