Adding foreign key performance

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/