Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity
От | David Rowley |
---|---|
Тема | Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity |
Дата | |
Msg-id | CAApHDvpy1Goh=tmZKDvJ+3Uqb69r8i3U09_m9+P4NBertCyVmw@mail.gmail.com обсуждение исходный текст |
Ответ на | Fwd: Inefficient use of index scan on 2nd column of composite index during concurrent activity (Durgamahesh Manne <maheshpostgres9@gmail.com>) |
Ответы |
Re: Inefficient use of index scan on 2nd column of composite index during concurrent activity
|
Список | pgsql-general |
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 meansquery 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 compositeindex ? 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
В списке pgsql-general по дате отправления: