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
        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.

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

Reply via email to