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

On Tue, 15 Oct, 2024, 15:15 David Rowley, <dgrowleyml(at)gmail(dot)com> wrote:

> On Sat, 12 Oct 2024 at 02:28, Durgamahesh Manne
> <maheshpostgres9(at)gmail(dot)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

>
>