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 

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?


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to