Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity - Mailing list pgsql-general

From Durgamahesh Manne
Subject Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity
Date
Msg-id CAJCZkoJEWdn3B57AWcnNn_4xycO33iKiUZZRXcy8EqyRHLv8fw@mail.gmail.com
Whole thread Raw
In response to Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-general


On Tue, 15 Oct, 2024, 15:15 David Rowley, <dgrowleyml@gmail.com> wrote:
On Sat, 12 Oct 2024 at 02:28, Durgamahesh Manne
<maheshpostgres9@gmail.com> wrote:
> 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 ?

It sounds like you might be asking about something we call "index skip
scans". Currently, PostgreSQL does not support these, however there is
work being done to add support and that might arrive in PG18.

There is some information about a possible workaround in [1] which may
be of use to you.

David

[1] https://wiki.postgresql.org/wiki/Loose_indexscan

Hi David

Thanks you for valuable info 

Regards,
Durga Mahesh 

pgsql-general by date:

Previous
From: David Rowley
Date:
Subject: Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity
Next
From: Dominique Devienne
Date:
Subject: Advice on efficiently logging outputs to PostgreSQL