Re: That EXPLAIN ANALYZE patch still needs work - Mailing list pgsql-hackers

From Larry Rosenman
Subject Re: That EXPLAIN ANALYZE patch still needs work
Date
Msg-id 02fb01c68b3f$bc8d5fa0$0202fea9@aus.pervasive.com
Whole thread Raw
In response to Re: That EXPLAIN ANALYZE patch still needs work  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
>> So the timing is clearly responsible for the additional time I'm
>> personally experiencing and very likely to be that for others also.
> 
> Well, that's certainly unsurprising, but the question is why it's such
> a large overhead for you when it's not on other apparently-similar
> kit. 
> 
> If anyone else is still following this discussion, could you try the
> test case Simon gave a bit earlier (select count(*) from 100000-row
> table, check \timing with and without explain analyze)?  If we could
> get a clearer picture of which platforms show the problem and which
> don't, maybe we could make some progress.
> 
> (BTW, I just tried it on my Apple Powerbook G4, and got results in
> line with what I get elsewhere.  So I've now tried it on three very
> different CPU types and OSes, and not duplicated Simon's problem on
> any of them.) 
> 

$ psql
Welcome to psql 8.1.4, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms      \h for help with SQL commands      \? for help with psql commands      \g
orterminate with semicolon to execute query      \q to quit
 

ler=# create table test1(id int);
CREATE TABLE
ler=# insert into test1 select * from generate_series(1,100000);
INSERT 0 100000
ler=# \timing
Timing is on.
ler=# select count(*) from test1;count
--------100000
(1 row)

Time: 39.191 ms
ler=# explain analyze select count(*) from test1;                                                    QUERY PLAN

----------------------------------------------------------------------------
----------------------------------------Aggregate  (cost=1988.18..1988.19 rows=1 width=0) (actual
time=282.899..282.901 rows=1 loops=1)  ->  Seq Scan on test1  (cost=0.00..1698.74 rows=115774 width=0) (actual
time=0.007..147.845 rows=100000 loops=1)Total runtime: 282.987 ms
(3 rows)

Time: 283.764 ms
ler=# \q
$ uname -a
FreeBSD thebighonker.lerctr.org 6.1-STABLE FreeBSD 6.1-STABLE #59: Thu Jun
1 09:40:47 CDT 2006
root@thebighonker.lerctr.org:/usr/obj/usr/src/sys/THEBIGHONKER  amd64
$ sysctl hw
hw.machine: amd64
hw.model: Intel(R) Xeon(TM) CPU 3.00GHz
hw.ncpu: 4
hw.byteorder: 1234
hw.physmem: 4286132224
hw.usermem: 4003151872
hw.pagesize: 4096
hw.floatingpoint: 1
hw.machine_arch: amd64
hw.realmem: 5368709120

[snip]

the database is 8.1.4
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: That EXPLAIN ANALYZE patch still needs work
Next
From: Tom Lane
Date:
Subject: Re: ADD/DROP INHERITS