Re: Postgres chooses slow query plan from time to time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kristjan Mustkivi <sonicmonkey(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Pgsql Performance <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: Postgres chooses slow query plan from time to time
Date: 2021-09-14 14:15:30
Message-ID: 589350.1631628930@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Kristjan Mustkivi <sonicmonkey(at)gmail(dot)com> writes:
> -> Index Scan Backward using player_balance_history_idx2 on
> mytable pbh (cost=0.70..21639.94 rows=3885 width=66) (actual
> time=5934.153..5934.153 rows=1 loops=1)
> Index Cond: ((cage_code = $3) AND (cage_player_id =
> $2) AND (modified_time < $5))
> Filter: (((product_code)::text = ($1)::text) AND
> ((balance_type)::text = ($4)::text))
> Rows Removed by Filter: 95589
> Buffers: shared hit=7623 read=18217

So indeed, the core issue is that that filter condition is very selective,
and applying it after the index scan is expensive. Perhaps it would help
to create an index that includes those columns along with cage_code and
cage_player_id. (It's not clear whether to bother with modified_time in
this specialized index, but if you do include it, it needs to be the last
column since you're putting a non-equality condition on it.)

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message sbob 2021-09-14 15:03:15 Re: EnterpriseDB
Previous Message Kristjan Mustkivi 2021-09-14 12:41:54 Re: Postgres chooses slow query plan from time to time