Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions - Mailing list pgsql-general

From David Rowley
Subject Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions
Date
Msg-id CAApHDvqWfGdUpTUp9s7AZYSeh44aLEXoBQS7UcfKM0zKhTCkiQ@mail.gmail.com
Whole thread Raw
In response to Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions
List pgsql-general
On Sat, 11 May 2024 at 13:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I do kind of wonder why it's producing both a hashagg and a Unique
> step --- seems like it should do one or the other.

It still needs to make the duplicate groups from parallel workers unique.

David



pgsql-general by date:

Previous
From: David Rowley
Date:
Subject: Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions
Next
From: WU Yan
Date:
Subject: Unnecessary buffer usage with multicolumn index, row comparison, and equility constraint