> >> It's not exactly easy to do, because (a) none of this information
> >> is exposed outside tuplesort.c, and (b) the tuplesortstate object
> >> is probably gone by the time EXPLAIN ANALYZE runs, anyway.
> > Hmm. Ok. Don't know enough about those parts of the code to comment on
> > that, but I'll certainly take your word for it :-)
> I take back point (b) --- the state object is released at ExecutorEnd,
> and EXPLAIN ANALYZE examines the tree before doing that, so if we added
> some kind of reporting function to tuplesort.c's API it'd be doable
> easily enough.
> What do you think the output should look like?  The first thought that
> comes to mind is to add "method=memory" (or disk or top-N) to the
> "actual" annotation:
> regression=# explain analyze select * from tenk1 order by fivethous limit 100;
>                                                        QUERY PLAN
> ------------------------------------------------------------------------------------------------------------------------
>  Limit  (cost=840.19..840.44 rows=100 width=244) (actual 
> time=140.511..141.604 rows=100 loops=1)
>    ->  Sort  (cost=840.19..865.19 rows=10000 width=244) (actual 
> time=140.492..140.880 rows=100 loops=1 method=top-N)
>                          ^^^^^^^^^^^^
>          Sort Key: fivethous
>          ->  Seq Scan on tenk1  (cost=0.00..458.00 rows=10000 width=244) 
> (actual time=0.074..51.849 rows=10000 loops=1)
>  Total runtime: 143.089 ms
> (5 rows)

Looks pretty good to me. Easy to find and hard to misunderstand :)


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to