Pgsql vs MS-Sql7

Hi All, I'm currently involved in a hardware/software solution for an 
insurance firm in Qld, Australia.  The Software vendor had originally spec'd 
their app as running on Postgreql7.1.3, but as of today have now advised that 
due to incompatibilities in the odbc driver they will only support MS-SQL7..

At this time I have minimal information to go on, but the issues are:[with my 
comments in square brackets]

1. Client enquiry screen is slow to load, esp when there are a large list of 
clients in the table..eg. PGSQL = 20sec, SQL7=2sec

[my gut feeling is that this is a badly formated query, or the indexes are 
inappropriate]

2. Table conflict errors when saving data.  Users encounter rollback errors 
when trying to save at the same time to the database.

[possible a  poorly designed query once again, providing wrong type of table 
locking,etc.]

3. Invoice data is slow to bring up (PGSQL=30sec, SQL7=1sec)

4. Timestamp incompatibility

[the old datetime/timestamp issue, which I believe is easily fixed]


Next week I expect to receive a demo install to check and see if I can 
recreate the issues, and speed compare against SQL7, but my questions on this 
for the list are:

	- Is there an effective way to debug the speed issues?? If I just create a 
logfile in the odbc driver, it will only tell me about failures or erors won't 
it??

	- Is there a way to trap the queries that are being sent to the Database 
backend?? - That way I can check if the issue is an optimisation one or not??


Overall I'm expecting that there maybe some very basic (and quickly fixed) 
design or implementation issues with this vendor's product, and I'm hoping to 
solve it or at least get it on track abit, cause I've just spent the last 
month preparing a range of other apps to function for this client based on the 
Postgresql backend..

I realise I haven't given much to go on, but I'd appreciate any pointers to 
debugging the odbc connection so I can come back to both the client and the 
vendor with some positive feedback.

Thanks for reading this far,

Dale