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@xxxxxxxxxx
web: www.askesis.nl
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
