Dimitrios Apostolou <jimis@gmx.net> writes:
> On Fri, 10 May 2024, Tom Lane wrote:
>> I'd say the blame lies with that (probably-default) estimate of
>> just 200 distinct rows. That means the planner expects to have
>> to read about 5% (10/200) of the tables to get the result, and
>> that's making fast-start plans look bad.
> In any case, even after the planner decides to execute the terrible plan
> with the parallel seqscans, why doesn't it finish right when it finds 10
> distinct values?
That plan can't emit anything at all till it finishes the Sort.
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.
> Thanks, I'll save the ANALYZE as the last step; I feel it's a good
> opportunity to figure out more details about how postgres works. Plus I
> expect ANALYZE to last a couple of days, so I should first find quiet time
> for that. :-)
It really should not take too long --- it reads a sample, not the
whole table.
regards, tom lane