Fwd: Inefficient use of index scan on 2nd column of composite index during concurrent activity

[Durgamahesh Manne <maheshpostgres9@xxxxxxxxx>]

---------- Forwarded message ---------
From: Durgamahesh Manne <maheshpostgres9@xxxxxxxxx>
Date: Mon, Oct 7, 2024 at 10:01 AM
Subject: Inefficient use of index scan on 2nd column of composite index during concurrent activity
To: <pgsql-in-general@xxxxxxxxxxxxxx>

Hi team 

Second column of composite index not in use effectively with index scan  when using second column at where clause

I have composite index on (placedon,id) of test 

When quering  select * from test where id = '4234';

Value of id changes and during concurrent activity and cpu utilization increased toomuch  that i have observed which means query plan changed why

I could see index scan with explain for it 

Is there any way to keep index scan for it during even on concurrency rather than seperate index on second column of composite index ?

Hope everyone understand this 

Regards,

Durga Mahesh 

Hi Greg 

you mentioned that below

(please start a new thread in the future rather than replying to an existing one)

You cannot query on b and use an index on (a,b) as you observed. However, you can have two indexes:

index1(a)

index2(b)

Postgres will be able to combine those when needed in the case where your WHERE clause needs to filter by both columns. So then you no longer need the two-column index.

Hi Greg ,

Here not using composite index on ordinary table.

Composite index that i use on partitioned table is mandatory for use to replicate data to target using pglogical  (sorry this is not mentioned earlier)

composite key (placedon,id) 

In concurrent mode if i use id at where clause then query plan for that id column changes 

How to mitigate it rather than use seperate index for id to continue without change in query plan (index scan) during concurrent activity 

I hope you understand this 

Regards,

Durga Mahesh 

Cheers,

Greg