Re: Air-traffic benchmark
От
A. Kretschmer
Тема
Re: Air-traffic benchmark
Дата
Msg-id
20100107135900.GC9884@a-kretschmer.de
Ответ на
Re: Air-traffic benchmark (Lefteris)
Список
Дерево обсуждения
Air-traffic benchmark Lefteris <lsidir@gmail.com>
Re: Air-traffic benchmark Simon Riggs <simon@2ndQuadrant.com>
Re: Air-traffic benchmark "Gurgel, Flavio" <flavio@4linux.com.br>
Re: Air-traffic benchmark "A. Kretschmer" <andreas.kretschmer@schollglas.com>
Re: Air-traffic benchmark Lefteris <lsidir@gmail.com>
Re: Air-traffic benchmark "A. Kretschmer" <andreas.kretschmer@schollglas.com>
Re: Air-traffic benchmark hubert depesz lubaczewski <depesz@depesz.com>
Re: Air-traffic benchmark Greg Smith <greg@2ndquadrant.com>
Re: Air-traffic benchmark Arjen van der Meijden <acmmailing@tweakers.net>
Re: Air-traffic benchmark Lefteris <lsidir@gmail.com>
Re: Air-traffic benchmark "A. Kretschmer" <andreas.kretschmer@schollglas.com>
Re: Air-traffic benchmark Jochen Erwied <jochen@pgsql-performance.erwied.eu>
Re: Air-traffic benchmark Lefteris <lsidir@gmail.com>
Re: Air-traffic benchmark Alvaro Herrera <alvherre@commandprompt.com>
Re: Air-traffic benchmark Alvaro Herrera <alvherre@commandprompt.com>
Re: Air-traffic benchmark Craig James <craig_james@emolecules.com>
Re: Air-traffic benchmark Lefteris <lsidir@gmail.com>
Re: Air-traffic benchmark Ivan Voras <ivoras@freebsd.org>
Re: Air-traffic benchmark Lefteris <lsidir@gmail.com>
Re: Air-traffic benchmark Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: Air-traffic benchmark Ivan Voras <ivoras@freebsd.org>
Re: Air-traffic benchmark Lefteris <lsidir@gmail.com>
Re: Air-traffic benchmark Greg Smith <greg@2ndquadrant.com>
Re: Air-traffic benchmark Lefteris <lsidir@gmail.com>
Re: Air-traffic benchmark Lefteris <lsidir@gmail.com>
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
В списке pgsql-performance по дате отправления