Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions

Поиск
Список
Период
Сортировка
От Dimitrios Apostolou
Тема Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions
Дата
Msg-id 98c715d1-22f4-0fc1-1997-6236873c13de@gmx.net
обсуждение исходный текст
Ответ на Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-general
On Tue, 14 May 2024, David Rowley wrote:

> On Tue, 14 May 2024 at 00:41, Dimitrios Apostolou <jimis@gmx.net> wrote:
>>
>> On Sat, 11 May 2024, David Rowley wrote:
>>> It will. It's just that Sorting requires fetching everything from its subnode.
>>
>> Isn't it plain wrong to have a sort step in the plan than? The different
>> partitions contain different value ranges with no overlap, and the last
>> query I posted doesn't even contain an ORDER BY clause, just a DISTINCT
>> clause on an indexed column.
>
> The query does contain an ORDER BY, so if the index is not chosen to
> provide pre-sorted input, then something has to put the results in the
> correct order before the LIMIT is applied.

The last query I tried was:

SELECT DISTINCT workitem_n FROM test_runs_raw LIMIT 10;

See my message at

[1] https://www.postgresql.org/message-id/69077f15-4125-2d63-733f-21ce6eac4f01%40gmx.net

Will re-check things and report back with further debugging info you asked
for later today.


Dimitris




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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions
Следующее
От: Dimitrios Apostolou
Дата:
Сообщение: Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions