Re: Optimizing select count query which often takes over 10 seconds

Поиск
Список
Период
Сортировка
От Alban Hertroys
Тема Re: Optimizing select count query which often takes over 10 seconds
Дата
Msg-id CAF-3MvOwMz+4LqaS4Dj4LQKn1KQi0RhT-Gr1n6pfNkk30XvALw@mail.gmail.com
обсуждение исходный текст
Ответ на Optimizing select count query which often takes over 10 seconds  (Alexander Farber <alexander.farber@gmail.com>)
Ответы Re: Optimizing select count query which often takes over 10 seconds  (Alexander Farber <alexander.farber@gmail.com>)
Re: Optimizing select count query which often takes over 10 seconds  (Alexander Farber <alexander.farber@gmail.com>)
Список pgsql-general
On 24 January 2013 10:57, Alexander Farber <alexander.farber@gmail.com> wrote:
# explain analyze select count(id) from (
            select id,
                   row_number() over(partition by yw order by money
desc) as ranking
            from pref_money
        ) x
        where x.ranking = 1 and id='OK452217781481';
                                                                QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=63694.22..63694.23 rows=1 width=82) (actual
time=4520.719..4520.719 rows=1 loops=1)
   ->  Subquery Scan x  (cost=48519.10..63694.19 rows=11 width=82)
(actual time=4470.620..4520.710 rows=6 loops=1)
         Filter: ((x.ranking = 1) AND ((x.id)::text = 'OK452217781481'::text))
         ->  WindowAgg  (cost=48519.10..57190.58 rows=433574 width=26)
(actual time=4293.315..4491.652 rows=429803 loops=1)
               ->  Sort  (cost=48519.10..49603.03 rows=433574
width=26) (actual time=4293.306..4352.544 rows=429803 loops=1)
                     Sort Key: pref_money.yw, pref_money.money
                     Sort Method:  external sort  Disk: 15856kB

It's sorting on disk. That's not going to be fast. Indeed, it's taking nearly all the time the query takes (4.4s for this step out of 4.5s for the query).
 
                     ->  Seq Scan on pref_money  (cost=0.00..7923.74
rows=433574 width=26) (actual time=0.006..41.907 rows=429803 loops=1)

And then it's doing a sequential scan to sort the data. I suspect that's because it's sorting on disk. Then again, this only takes 42ms, just once (loops=1), so perhaps a seqscan is indeed the fastest approach here (actually, wow, it scans 10000 records/ms - rows are 26 bytes wide, so that's 260MB/s! I'm doubting my math here...).

 Total runtime: 4525.662 ms
(9 rows)

Thank you for any hints
Alex


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.

В списке pgsql-general по дате отправления:

Предыдущее
От: "Gauthier, Dave"
Дата:
Сообщение: Re: DB alias ?
Следующее
От: Alexander Farber
Дата:
Сообщение: Re: Optimizing select count query which often takes over 10 seconds