Date: Thu, 7 Jan 2010 14:32:25 +0100
From: "A. Kretschmer" <andreas.kretschmer@schollglas.com>
To: pgsql-performance@postgresql.org
Subject: Re: Air-traffic benchmark
Message-ID: <20100107133225.GB9884@a-kretschmer.de>
References: <852badbc1001070438j36eb10d3qa22398ffcbef405f@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <852badbc1001070438j36eb10d3qa22398ffcbef405f@mail.gmail.com>
User-Agent: Mutt/1.5.9i

In response to Lefteris :
> 
> airtraffic=# EXPLAIN ANALYZE SELECT "DayOfWeek", count(*) AS c FROM
> ontime WHERE "Year" BETWEEN 2000 AND 2008 GROUP BY "DayOfWeek" ORDER
> BY c DESC;
>                                                                QUERY
> PLAN
> ------------------------------------------------------------------------------------------------------------------------------------------
>  Sort  (cost=7407754.12..7407754.13 rows=4 width=2) (actual
> time=371188.821..371188.823 rows=7 loops=1)
>   Sort Key: (count(*))
>   Sort Method:  quicksort  Memory: 25kB
>   ->  HashAggregate  (cost=7407754.04..7407754.08 rows=4 width=2)
> (actual time=371163.316..371163.320 rows=7 loops=1)
>         ->  Seq Scan on ontime  (cost=0.00..7143875.40 rows=52775727
> width=2) (actual time=190938.959..346180.079 rows=52484047 loops=1)
>               Filter: (("Year" >= 2000) AND ("Year" <= 2008))
>  Total runtime: 371201.156 ms
> (7 rows)
> 
> 
> I understand that the problem here is the memory used by the sort
> method. *But*, I already changed the work_mem parameter to 6gigs:)

No.

The problem here is the Seq-Scan. It returns about 52.000.000 rows,
approximately roughly table, it needs 346 seconds.

The sort needs only 25 KByte and only 0.02ms.


Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431  2EB0 389D 1DC2 3172 0C99