Re: BUG #16089: Index only scan does not happen but expected
От | Dmitry Dolgov |
---|---|
Тема | Re: BUG #16089: Index only scan does not happen but expected |
Дата | |
Msg-id | 20191030141316.lkzqxc5isoc4xbgz@localhost обсуждение исходный текст |
Ответ на | BUG #16089: Index only scan does not happen but expected (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
RE: BUG #16089: Index only scan does not happen but expected
|
Список | pgsql-bugs |
Thank you for the report. > On Wed, Oct 30, 2019 at 12:54:31PM +0000, PG Bug reporting form wrote: > The following bug has been logged on the website: > > Bug reference: 16089 > Logged by: Stepan Yankevych > Email address: stepya@ukr.net > PostgreSQL version: 11.5 > Operating system: CentOS Linux release 7.3.1611 (Core) > Description: > > Not a real issue but rather performance leak. The issue is > reproducible on the version 11.5 and 12.0 as well. Does it mean, that on the previous versions you observed different behaviour? > The execution plan shows reading full partitions.l1_snapshot_201811 > Why do we need to read data from table. We have all needed information > in the index that is smaller. I would expect index only scan > (something like Oracle version of index fast full scan ) After a few experiments with this schema it looks like planner sometimes prefers seq scan (parallel seq scan) instead of using the index due to random read being more costly than sequential reads, even if it's necessary to read more pages. And in fact at least in my tests this was indeed faster. If you want to try out, it's possible to set random_page_cost lower and seq_page_cost higher, and planner will most likely choose a different plan, but whether it would be better or not is not clear.
В списке pgsql-bugs по дате отправления: