RE: BUG #16089: Index only scan does not happen but expected

>> And in fact at least in my tests this was indeed faster
Can you show execution plan when index is used?
Does it uses Index only scan or index scan and table scan ?

STEPAN YANKEVYCH
Software Engineering Team Leader
Software Engineering Manager
OCA
 
Office: +380 322 424 642 x 58840   Cell: +380 96 915 9551   Email: stepan_yankevych(at)epam(dot)com
Lviv, Ukraine   epam.com
 
 
CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or entity(ies) to which it is addressed and contains information that is legally privileged and confidential. If you are not the intended recipient, or the person responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. All unintended recipients are obliged to delete this message and destroy any printed copies.
 

-----Original Message-----
From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Sent: Wednesday, October 30, 2019 16:13
To: stepya(at)ukr(dot)net; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16089: Index only scan does not happen but expected

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(at)ukr(dot)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.