Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism

Andres Freund <andres(at)anarazel(dot)de> writes:
> Right now we don't indicate that a top-n sort is going to be used in
> EXPLAIN, just EXPLAIN ANALYZE.

Given the way that's implemented, I doubt that we can report it
reliably in EXPLAIN.

> It's also noticable that we preposterously assume that the sort actually
> will return exactly the number of rows in the table, despite being a
> top-n style sort.

In general, we report nodes below LIMIT with their execute-to-completion
cost and rowcount estimates. Doing differently for a top-N sort would
be quite confusing, I should think.

> That seems bad for costing of the parallel query,
> because it think we'll assume that costs tups * parallel_tuple_cost?

If the parallel query stuff doesn't understand about LIMIT, that's
a bug independently of top-N sorts.

regards, tom lane