Fw: Re: Bitmap scan seem like such a strange choice when "limit 1" - Mailing list pgsql-general

From Klaudie Willis
Subject Fw: Re: Bitmap scan seem like such a strange choice when "limit 1"
Date
Msg-id gaWaPH2J0kYNq2ZfeVlM2R5JjFSPrXYeo8P8l23JGaL8z9WxfmbVWSMBPlvOPh0jlskix5fnxruBpDNKAjLax_VoWZE7TZQ7pHxBPkRHw3E=@protonmail.com
Whole thread Raw
In response to Bitmap scan seem like such a strange choice when "limit 1"  (Klaudie Willis <Klaudie.Willis@protonmail.com>)
List pgsql-general
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, September 7, 2020 9:04 AM, Klaudie Willis <Klaudie.Willis@protonmail.com> wrote:

 > Maybe the right way to improve this is to bypass add_paths_to_append_rel
 > entirely when there's exactly one surviving child rel, and make it
 > just use all the surviving paths for that child.
 > regards, tom lane

Does this classify as a bug, or is it "by design"? Should I submit one for PG13beta3? To me, this seems like quite a
straightforward case. Big database partitioned, two key lookups, both indexed where one key isolates a partition, and
witha limit constraint. Yet it chooses a plan that is 1000x slower than the optimal plan. 

K





pgsql-general by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Fix typo in Comments of HandleProcSignalBarrierInterrupt
Next
From: Klaudie Willis
Date:
Subject: Fw: Re: Bitmap scan seem like such a strange choice when "limit 1"