From: | "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Air-traffic benchmark |
Date: | 2010-01-07 13:59:00 |
Message-ID: | 20100107135900.GC9884@a-kretschmer.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | A. Kretschmer | 2010-01-07 14:02:44 | Re: Air-traffic benchmark |
Previous Message | Lefteris | 2010-01-07 13:47:36 | Re: Air-traffic benchmark |