Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism
Date
Msg-id 1135.1558650703@sss.pgh.pa.us
Whole thread Raw
In response to Top-N sorts in EXPLAIN, row count estimates, and parallelism  (Andres Freund <andres@anarazel.de>)
Responses Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism  (Andres Freund <andres@anarazel.de>)
Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
Next
From: Tom Lane
Date:
Subject: Re: Why could GEQO produce plans with lower costs than the standard_join_search?