Re: [PATCH] Incremental sort (was: PoC: Partial sort)

James Coleman <jtc331@gmail.com>

From: James Coleman <jtc331@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>, Rafia Sabih <rafia.pghackers@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Simon Riggs <simon@2ndquadrant.com>, Shaun Thomas <shaun.thomas@2ndquadrant.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-03-13T17:06:33Z
Lists: pgsql-hackers

Attachments

On Thu, Mar 12, 2020 at 5:53 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> I gave this a very quick look; I don't claim to understand it or
> anything, but I thought these trivial cleanups worthwhile.  The only
> non-cosmetic thing is changing order of arguments to the SOn_printf()
> calls in 0008; I think they are contrary to what the comment says.

Yes, I think you're correct (re: 0008).

They all look generally good to me, and are included in the attached
patch series.

> I don't propose to commit 0003 of course, since it's not our policy;
> that's just to allow running pgindent sanely, which gives you 0004
> (though my local pgindent has an unrelated fix).  And after that you
> notice the issue that 0005 fixes.

Is there a page on how you're supposed to run pgindent/when stuff like
this does get added/etc.? It's all a big mystery to me right now.

Also, I noticed some of the pgindent changes aren't for changes in
this patch series; I have that as a separate patch, but not attached
because I see that running pgindent locally generates a massive patch,
so I'm assuming we just ignore those for now?

> I did notice that show_incremental_sort_group_info() seems to be doing
> things in a hard way, or something.  I got there because it throws this
> warning:
>
> /pgsql/source/master/src/backend/commands/explain.c: In function 'show_incremental_sort_group_info':
> /pgsql/source/master/src/backend/commands/explain.c:2766:39: warning: passing argument 2 of 'lappend' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>     methodNames = lappend(methodNames, sortMethodName);
>                                        ^~~~~~~~~~~~~~
> In file included from /pgsql/source/master/src/include/access/xact.h:20,
>                  from /pgsql/source/master/src/backend/commands/explain.c:16:
> /pgsql/source/master/src/include/nodes/pg_list.h:509:14: note: expected 'void *' but argument is of type 'const char *'
>  extern List *lappend(List *list, void *datum);
>               ^~~~~~~
> /pgsql/source/master/src/backend/commands/explain.c:2766:39: warning: passing 'const char *' to parameter of type 'void *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
>                         methodNames = lappend(methodNames, sortMethodName);
>                                                            ^~~~~~~~~~~~~~
> /pgsql/source/master/src/include/nodes/pg_list.h:509:40: note: passing argument to parameter 'datum' here
> extern List *lappend(List *list, void *datum);
>                                        ^
> 1 warning generated.
>
> (Eh, it's funny that GCC reports two warnings about the same line, and
> then says there's one warning.)

I had seen this before I sent the patch, but then it seemed like it
disappeared, so I didn't come back to it; maybe I just missed it in my
buffer.

I do see it now, and moving the declarations into each relevant block
(rather than trying to share them) seems to fix it. I think that's
correct anyway, since before they were technically being assigned to
more than once which seems wrong for const.

I have this change locally and will include it in my next patch version.

> I suppose you could silence this by adding pstrdup(), and then use
> list_free_deep (you have to put the sortMethodName declaration in the
> inner scope for that, but seems fine).  Or maybe there's a clever way
> around it.
>
> But I hesitate to send a patch for that because I think the whole
> function is written by handling text and the other outputs completely
> separately -- but looking for example show_modifytable_info() it seems
> you can do ExplainOpenGroup, ExplainPropertyText, ExplainPropertyList
> etc in all explain output modes, and those routines will care about
> emitting the data in the correct format, without having the
> show_incremental_sort_group_info function duplicate everything.

I'm not sure how that would work: those functions (for
EXPLAIN_FORMAT_TEXT) all add newlines, and this code is intentionally
trying to avoid too many lines.

I'm open to suggestions though.

> HTH.  I would really like to get this patch done for pg13.

As would I!

James

Commits

  1. Further adjustments to Hashagg EXPLAIN ANALYZE output

  2. Rework EXPLAIN format for incremental sort

  3. Fix typos and improve incremental sort comments

  4. Stabilize incremental_sort tests

  5. Minor improvements in Incremental Sort explain

  6. Consider Incremental Sort paths at additional places

  7. Fix representation of SORT_TYPE_STILL_IN_PROGRESS.

  8. Fix failures in incremental_sort due to number of workers

  9. Fix show_incremental_sort_info with force_parallel_mode

  10. Implement Incremental Sort

  11. Fix handling of "Subplans Removed" field in EXPLAIN output.

  12. Fix EXPLAIN (SETTINGS) to follow policy about when to print empty fields.

  13. Ensure plpgsql result tuples have the right composite type marking.

  14. Propagate sort instrumentation from workers back to leader.

  15. Make new regression test case parallel-safe, and improve its output.

  16. Push limit through subqueries to underlying sort, where possible.

  17. Fix inappropriate printing of never-measured times in EXPLAIN.

  18. Fix some infelicities in EXPLAIN output for parallel query plans.