Dimitrios Apostolou <jimis@xxxxxxx> 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
