Re: Bad planner decision - bitmap scan instead of index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Frank Schoep <frank@xxxxxxx> writes:
> Limit  (cost=4002.04..4002.29 rows=100 width=48) (actual  
> time=1469.565..1470.097 rows=100 loops=1)
>     ->  Sort  (cost=3997.29..4031.18 rows=13556 width=48) (actual  
> time=1460.958..1467.993 rows=2000 loops=1)
>           Sort Key: name
>           ->  Bitmap Heap Scan on movies  (cost=86.45..3066.90  
> rows=13556 width=48) (actual time=20.522..77.889 rows=13640 loops=1)
>                 Recheck Cond: (letter = 'T'::bpchar)
>                 ->  Bitmap Index Scan on movies_letter   
> (cost=0.00..86.45 rows=13556 width=0) (actual time=18.452..18.452  
> rows=13658 loops=1)
>                       Index Cond: (letter = 'T'::bpchar)
> Total runtime: 1474.821 ms

Why is the sort step so slow? Sorting a mere 13k rows shouldn't take
very long.  Maybe you are overrunning work_mem and it's falling back
to a disk sort ... what is work_mem set to?

Another theory is that you are using a locale in which strcoll() is
horridly expensive :-(

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux