Re: BUG #16089: Index only scan does not happen but expected - Mailing list pgsql-bugs

From Dmitry Dolgov
Subject Re: BUG #16089: Index only scan does not happen but expected
Date
Msg-id 20191030141316.lkzqxc5isoc4xbgz@localhost
Whole thread Raw
In response to BUG #16089: Index only scan does not happen but expected  (PG Bug reporting form <noreply@postgresql.org>)
Responses RE: BUG #16089: Index only scan does not happen but expected
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: insert into inet from text automatically adding subnet
Next
From: Stepan Yankevych
Date:
Subject: RE: BUG #16089: Index only scan does not happen but expected