Take a look at the RAISE command and consider sticking a couple of RAISE Notice ''Here I am!'' statements inside the ticket add routine to see exactly which step is taking a long time.
Also if you haven't started and stopped AOLserver in a long time you might try that. Execution plans for PL/pgSQL functions are created once per backend lifetime, and if you follow our advice on linux and keep your backends alive forever (to avoid the zombie process issue on Linux), vacuuming may analyze the tables but the function plan won't change.
Stopping AOLserver will release those backends and when they restart a new execution plan will be made for the various PL/pgSQL procs involved.
My own site stays up literally for months on end ... if yours is like that and if you started out with very few tickets your functions may be executing sequential scan plans rather than index scans.
And of course there may just be some missing indexes in the datamodel, too ... (the RAISE hack should help you find the exact step which is taking a long time)
The add function shouldn't be doing an permissions checks so I doubt upgrading to new permissions would help this. However, you should be able to run the permissions upgrades for 4.6.1 on your 4.5 database with no problem - on a test version first, of course, not your live data!
