Re: Performance PG 8.0 on dual opteron / 4GB / 3ware
От | Joost Kraaijeveld |
---|---|
Тема | Re: Performance PG 8.0 on dual opteron / 4GB / 3ware |
Дата | |
Msg-id | 1131354179.5877.59.camel@Panoramix обсуждение исходный текст |
Ответ на | Re: Performance PG 8.0 on dual opteron / 4GB / 3ware ("Dave Page" <dpage@vale-housing.co.uk>) |
Список | pgsql-performance |
Hi Dave, On Mon, 2005-11-07 at 08:51 +0000, Dave Page wrote: > > On Sun, 2005-11-06 at 15:26 -0500, Tom Lane wrote: > > > I'm confused --- where's the 82sec figure coming from, exactly? > > >From actually executing the query. > > > > >From PgAdmin: > > > > -- Executing query: > > select objectid from prototype.orders > > > > Total query runtime: 78918 ms. > > Data retrieval runtime: 188822 ms. > > 1104379 rows retrieved. > > > > > > > We've heard reports of performance issues in PgAdmin with large > > > result sets ... if you do the same query in psql, what happens? > > jkr@Panoramix:~/postgresql$ time psql muntdev -c "select objectid from > > prototype.orders" > output.txt > > > > real 0m5.554s > > user 0m1.121s > > sys 0m0.470s > > > > > > Now *I* am confused. What does PgAdmin do more than giving > > the query to > > the database? > > Nothing - it just uses libpq's pqexec function. The speed issue in > pgAdmin is rendering the results in the grid which can be slow on some > OS's due to inefficiencies in some grid controls with large data sets. > That's why we give 2 times - the first is the query runtime on the > server, the second is data retrieval and rendering (iirc, it's been a > while). That is what I thought, but what could explain the difference in query runtime (78 seconds versus 5 seconds) ? -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: J.Kraaijeveld@Askesis.nl web: www.askesis.nl
В списке pgsql-performance по дате отправления: