Re: Nested loops are killing throughput

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Nested loops are killing throughput
Дата
Msg-id
4769.1158678187@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Nested loops are killing throughput CG <cgg007@yahoo.com>
Re: Nested loops are killing throughput Tom Lane <tgl@sss.pgh.pa.us>
Re: Nested loops are killing throughput CG <cgg007@yahoo.com>
Re: Nested loops are killing throughput Tom Lane <tgl@sss.pgh.pa.us>
Re: Nested loops are killing throughput CG <cgg007@yahoo.com>
Re: Nested loops are killing throughput Tom Lane <tgl@sss.pgh.pa.us>
Re: Nested loops are killing throughput CG <cgg007@yahoo.com>
Re: Nested loops are killing throughput CG <cgg007@yahoo.com>
CG  writes:
>                     ->  Nested Loop  (cost=0.00..744.28 rows=1 width=16) (actual time=31.227..6980.765 rows=5436 loops=1)
>                           ->  Nested Loop  (cost=0.00..135.29 rows=101 width=16) (actual time=25.514..273.660 rows=5436 loops=1)
> ...
>                           ->  Index Scan using packet_status_puuid_pkey on packet_status dps  (cost=0.00..6.02 rows=1 width=16) (actual time=1.226..1.228 rows=1 loops=5436)
>                                 Index Cond: (dps.packet_uuid = "outer".packet_uuid)
>                                 Filter: ((status & 2) = 0)

One problem you've got is that the planner has no stats about the
selectivity of that status condition.  My advice would be to forget the
cute bitmask and store one or more plain boolean columns.  Easier to
write queries against and way more tractable statistically.
		regards, tom lane

В списке pgsql-sql по дате отправления
От: CG
Дата:
От: Ezequias Rodrigues da Rocha
Дата:
FAQ