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.
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 |