| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Klaudie Willis <Klaudie(dot)Willis(at)protonmail(dot)com> | 
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: Bitmap scan seem like such a strange choice when "limit 1" | 
| Date: | 2020-09-04 14:41:21 | 
| Message-ID: | 874451.1599230481@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
Klaudie Willis <Klaudie(dot)Willis(at)protonmail(dot)com> writes:
> I'd like to add, that when I do the same query DIRECTLY on the bigtable_y2020 (instead of the partition parent) it does change to "index scan" again.
Yeah.  I think the issue here is that add_paths_to_append_rel only
considers cheapest-total paths for the member relations.  Seeing
that it's already considering a slightly ridiculous number of
parallelization options, I'm hesitant to throw in cheapest-startup
considerations as well, for fear of blowing out planning time.
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rich Shepard | 2020-09-04 14:46:03 | Re: Check for duplicates before inserting new rows | 
| Previous Message | Rich Shepard | 2020-09-04 14:40:00 | Re: Check for duplicates before inserting new rows |