I have this query running on Greenplum 6(Postgres 9.4) too slow as it performing a sequential scan. But I am thinking why it's not performing an index backward scan to fetch the records since there is an index on the same column. explain analyse select * from tab1 where create_time > now() - interval '1d' order by create_time desc limit 20; https://explain.depesz.com/s/UTA7#html The index is a composite index (create_time,col2), could it be the reason behind sequential scan? I have already updated statistics of the table and also the bloat ≈5% only.

This is my table: CREATE TABLE IF NOT EXISTS public.ob_samples_sc5555 ( stamp timestamp(6) with time zone NOT NULL, oblvl smallint NOT NULL, olots integer NOT NULL, CONSTRAINT prk_ob_samples_sc5555 PRIMARY KEY (stamp, oblvl) ); This is my query: delete from ob_samples_sc5555 where stamp Finalize Aggregate (cost=10106164.53..10106164.54 rows=1 width=8) > > -> Gather (cost=10106163.59..10106164.50 rows=9 width=8) > Workers Planned: 9 > -> Partial Aggregate (cost=10105163.59..10105163.60 rows=1 width=8) > -> Parallel Seq Scan on ob_samples_sc5555 (cost=0.00..9917330.49 rows=75133240 width=0) > Filter: (stamp JIT: > Functions: 6 > Options: Inlining true, Optimization true, Expressions true, Deforming true Why does PG13 use a seq scan instead of primary key, while the column stamp is the first column of the PK?