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

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
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
Date: 2019-10-30 14:13:16
Message-ID: 20191030141316.lkzqxc5isoc4xbgz@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Stepan Yankevych 2019-10-30 14:18:09 RE: BUG #16089: Index only scan does not happen but expected
Previous Message Tom Lane 2019-10-30 14:05:34 Re: insert into inet from text automatically adding subnet