Re: PsqlODBC slow on UNION queries
От | Zoltan Boszormenyi |
---|---|
Тема | Re: PsqlODBC slow on UNION queries |
Дата | |
Msg-id | 43C4C670.5020407@dunaweb.hu обсуждение исходный текст |
Ответ на | Re: PsqlODBC slow on UNION queries (Ludek Finstrle <luf@pzkagis.cz>) |
Ответы |
Re: PsqlODBC slow on UNION queries
|
Список | pgsql-odbc |
Ludek Finstrle írta: >>>If I set only Declare/Fetch or both to ON, opening the VIEW in Access >>>comes close to what I experinced in psql, e.g. it appears almost instantly >>>when using UNION ALL, and just under 7 seconds when using UNION. >>> >>>I don't remember which ODBC settings I used for the Windows2000 client >>>and PowerBuilder, I am not near that machine. I will recheck it when >>>I get back to my workplace next monday. >>> >>> >>There is another thing. psqlODBC driver simulate SQLColAttributes (I wrote >>it on the fly so it could be different ODBC API) throught call >>the query and then get the columns information before query is already >>open. So it could be the time bottleneck. >>I try describe it better: >>SQLPrepare, SQLColAttributes (this call the statement for getting columns >>information), SQLExecute (this call the statement for result). >> >>If you want trace it down the good start point is turn mylog output on >>and read the result in C:\mylog_XXXX.log (or txt extension?). >> >> > >I forgot. Feel free to send the mylog output here to list. We can >help you to decode it ;-) > > I will, when I am back to my workplace. In the meantime, I have set MyLog on in WinXP under VMWare here, but Access produced some 120+ MB log and it wasn't even finished reading the records... I didn't feel like I have to send it to the list. ;-) Anyway, it turned out it used DECLARE CURSOR and it fetched 100 records at a time. Best regards, Zoltán Böszörményi
В списке pgsql-odbc по дате отправления: