On Tue, Sep 13, 2005 at 07:58:20AM -0400, Merlin Moncure wrote: > Can you give specific examples of cases that are not performing like you > expect? If possible, give a few queries with explain analyze times and > all that.
O.K. I have found one particular problem: 2005-09-13 14:43:02 LOG: statement: declare SQL_CUR03949008 cursor for SELECT * FROM t_umlpattern 2005-09-13 14:43:02 LOG: duration: 0.000 ms 2005-09-13 14:43:02 LOG: statement: fetch 1000 in SQL_CUR03949008 2005-09-13 14:43:22 LOG: duration: 20185.000 ms This command is executed while a model is loaded from the repository. The table definition is: CREATE TABLE t_umlpattern ( PatternID INTEGER DEFAULT nextval('"patternid_seq"'::text) NOT NULL PRIMARY KEY, PatternCategory VARCHAR(100), PatternName VARCHAR(150), Style VARCHAR(250), Notes TEXT, PatternXML TEXT, Version VARCHAR(50) ); It has just 23 rows but the PatternXML column is rather large. The table dump has over 900 kB. Now select * from t_umlpattern limit 2 takes 1500+ msec on the Windows machine and 60 on a comparable Linux machine. Both selects performed from remote PgAdmin. The same select performed localy on the windows machine takes 60 msec. So I guess the problem is in the transfer of the bigger amount of data from the Windows server. I put the dump at http://www.insula.cz/dali/misc/table.zip Could anybody confirm the difference? Thanks for any suggestions. Dalibor Sramek -- Dalibor Sramek http://www.insula.cz/dali \ In the eyes of cats / [EMAIL PROTECTED] \ all things / >H blog http://www.transhumanismus.cz/blog.php \ belong to cats. ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings