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 по дате отправления
От: Ezequias Rodrigues da Rocha
Дата: