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

In response to Lefteris :
> Thank you all for your answers!
> 
> Andrea, I see the other way around what you are saying:
> 
> Sort  (cost=7407754.12..7407754.13 rows=4 width=2) (actual
> time=371188.821..371188.823 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)
> 
> 
> I dont see the seq scan to ba a problem, and it is the correct choice
> here because Year spans from 1999 to 2009 and the query asks from 2000
> and on, so PG correctly decides to use seq scan and not index access.

Thats right.

But this is not a contradiction, this seq-scan *is* the real problem, not
the sort. And yes, as others said, increment the work_mem isn't the
solution. It is counterproductive, because you lost buffer-cache.


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