Re: Bitmap scan seem like such a strange choice when "limit 1"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bitmap scan seem like such a strange choice when "limit 1"
Дата
Msg-id 874451.1599230481@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bitmap scan seem like such a strange choice when "limit 1"  (Klaudie Willis <Klaudie.Willis@protonmail.com>)
Ответы Re: Bitmap scan seem like such a strange choice when "limit 1"  (Michael Lewis <mlewis@entrata.com>)
Список pgsql-general
Klaudie Willis <Klaudie.Willis@protonmail.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
doeschange 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



В списке pgsql-general по дате отправления:

Предыдущее
От: Rich Shepard
Дата:
Сообщение: Re: Check for duplicates before inserting new rows
Следующее
От: Rich Shepard
Дата:
Сообщение: Re: Check for duplicates before inserting new rows