Horton

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

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: James Coleman <jtc331@gmail.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>, Andreas Karlsson <andreas@proxel.se>
Date: 2020-03-31T16:31:26Z
Lists: pgsql-hackers 
On 2020-Mar-30, James Coleman wrote:

> +/* ----------------
> + *	 Instruementation information for IncrementalSort
> + * ----------------
> + */
> +typedef struct IncrementalSortGroupInfo
> +{
> +	int64		groupCount;
> +	long		maxDiskSpaceUsed;
> +	long		totalDiskSpaceUsed;
> +	long		maxMemorySpaceUsed;
> +	long		totalMemorySpaceUsed;
> +	Size		sortMethods; /* bitmask of TuplesortMethod */
> +} IncrementalSortGroupInfo;

There's a typo "Instruementation" in the comment, but I'm more surprised
that type Size is being used to store a bitmask.  It looks weird to me.
Wouldn't it be more reasonable to use bits32 or some such?  (I first
noticed this in the "sizeof(Size)" code that appears in the explain
code.)


OTOH, aesthetically it would seem to be better to define these values
using ones and increasing shifts (1 << 1 and so on), rather than powers
of two:

> + * TuplesortMethod is used in a bitmask in Increment Sort's shared memory
> + * instrumentation so needs to have each value be a separate bit.
>   */
>  typedef enum
>  {
>  	SORT_TYPE_STILL_IN_PROGRESS = 0,
> -	SORT_TYPE_TOP_N_HEAPSORT,
> -	SORT_TYPE_QUICKSORT,
> -	SORT_TYPE_EXTERNAL_SORT,
> -	SORT_TYPE_EXTERNAL_MERGE
> +	SORT_TYPE_TOP_N_HEAPSORT = 2,
> +	SORT_TYPE_QUICKSORT = 4,
> +	SORT_TYPE_EXTERNAL_SORT = 8,
> +	SORT_TYPE_EXTERNAL_MERGE = 16
>  } TuplesortMethod;

I don't quite understand why you skipped "1".  (Also, is the use of zero
a wise choice?)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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.