Re: Index no longer being used, destroying and recreating it restores use.

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Koen De Groote <kdg(dot)dev(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Index no longer being used, destroying and recreating it restores use.
Date: 2020-06-04 16:48:28
Message-ID: ac76ccc8-a504-fffd-39b9-67495e918553@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 6/4/20 9:43 AM, Tom Lane wrote:
> Koen De Groote <kdg(dot)dev(at)gmail(dot)com> writes:
>> I've got a table with about 30 million rows and a particular index that up
>> until recently was actively being used.
>> And then it stopped being used and the query that the index was made for,
>> is now doing sequential scans.
>> Deleting the index and creating it again, seems to fix the problem. The new
>> index, which is identical in composition, is being used and the query in
>> question no longer uses sequential scans.
>
> It's possible that the index had bloated to the point where the planner
> thought it was cheaper to use a seqscan. Did you make a note of the
> cost estimates for the different plans?

I missed the part where the OP pointed to a SO question. In that
question where links to explain.depesz.com output. So:

With index(https://explain.depesz.com/s/H5X9y):

Limit (cost=5964059.790..5964071.460 rows=100 width=3141) (actual
time=2534.648..2547.352 rows=100 loops=1)
Buffers: shared hit=30 read=27753
-> Gather Merge (cost=5959707.820..6516383.180 rows=4771170
width=3141) (actual time=2193.611..2542.835 rows=37400 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=30 read=27753
-> Sort (cost=5958707.790..5964671.760 rows=2385585
width=3141) (actual time=1833.278..1838.731 rows=12528 loops=3)
Sort Key: mike_romeo, quebec
Sort Method: quicksort Memory: 24449kB
Worker 0: Sort Method: quicksort Memory: 28634kB
Worker 1: Sort Method: quicksort Memory: 18065kB
Buffers: shared hit=30 read=27753
-> Parallel Bitmap Heap Scan on oscar mike_three
(cost=4282.840..1923544.730 rows=2385585 width=3141) (actual
time=150.297..659.047 rows=23586 loops=3)
Recheck Cond: ((zulu <= 'echo'::timestamp without
time zone) AND four AND (NOT bravo))
Heap Blocks: exact=9759
Buffers: shared read=27753
-> Bitmap Index Scan on foxtrot
(cost=0.000..2851.490 rows=5725405 width=0) (actual
time=245.459..245.459 rows=70759 loops=1)
Index Cond: (zulu <= 'echo'::timestamp
without time zone)
Buffers: shared read=2028
Planning time: 437.187 ms
Execution time: 2549.633 ms

W/O index(https://explain.depesz.com/s/n6bP):

Limit (cost=5975083.560..5975095.230 rows=100 width=3141) (actual
time=159708.476..159718.368 rows=100 loops=1)
Buffers: shared hit=1082 read=1798654
-> Gather Merge (cost=5970731.590..6527406.950 rows=4771170
width=3141) (actual time=159309.819..159713.861 rows=37400 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=1082 read=1798654
-> Sort (cost=5969731.570..5975695.530 rows=2385585
width=3141) (actual time=159214.623..159219.579 rows=12531 loops=3)
Sort Key: mike_romeo, quebec
Sort Method: quicksort Memory: 24459kB
Worker 0: Sort Method: quicksort Memory: 22650kB
Worker 1: Sort Method: quicksort Memory: 24038kB
Buffers: shared hit=1082 read=1798654
-> Parallel Seq Scan on oscar mike_three
(cost=0.000..1934568.500 rows=2385585 width=3141) (actual
time=159.800..158018.961 rows=23586 loops=3)
Filter: (four AND (NOT bravo) AND (zulu <=
'echo'::timestamp without time zone))
Rows Removed by Filter: 8610174
Buffers: shared hit=1014 read=1798652
Planning time: 0.807 ms
Execution time: 159720.208 ms

>
> regards, tom lane
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Susan Joseph 2020-06-04 16:50:58 Re: PostgreSQL 11 with SSL on Linux
Previous Message Tom Lane 2020-06-04 16:43:32 Re: Index no longer being used, destroying and recreating it restores use.