Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJJnd-0004Zo-Bn for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2020 16:31:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jJJnc-0002jr-8Q for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2020 16:31:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJJnb-0002jj-Pq for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2020 16:31:36 +0000 Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jJJnY-0004AA-E9 for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2020 16:31:34 +0000 Received: by mail-qk1-x741.google.com with SMTP id 139so13786171qkd.9 for ; Tue, 31 Mar 2020 09:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Hl9yT/bkftkW5JfLO4e7pjyBpoHrPPnfxgHXHC/mtqo=; b=ca4ySyrah9nzujC9cGtua41/OdV1s58XoWDG3GHimmhfvski3BHn+adOS56RonD4J2 1aWh0doF/DBRYTH7seM/ATFgKoHeaSAYlUgoFtWUAydhHvjiwfp+o8BW1RSaBEVR4Cm+ jaBy4Lcdq1ZbNAPZBspeM2ue8G9ZNy/65cfjKReKf4s2W40yRt9vv0j8RtV1bQyZnt1N xdIYDID22wyi+jxqmc3gKKjRLcDiChPGpew5hW2s91gCMMq8Q1b9bR+ykQ41oIoG6mJj BIbre5fm8+OXtpcMauDaRPx2MD3prleq7+i202rFxCs3ZhHm1GKKnYBszqOuAKnYbVoX r8mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Hl9yT/bkftkW5JfLO4e7pjyBpoHrPPnfxgHXHC/mtqo=; b=atKp/Nr0oOIObP+CK3ePhKETRRc0l9Wj+lxVFh52dFwxBbfFRWIieaenmKm3aj6Xug W+V+Qux43jjtH6PrZoXMbMyOotaJQNyK75hyClood5y7c3O7tHIujIWpuKUJDRFFRI8n G2uGblT/RI61j/VoR8Lqvla5vMSslJT5vV8i5Fo+Vfut4SrTDK1Nxr8FCQxQ+lrvsS0q tpCNKd6C/hpEo8ZavgwcxlUIAXGlkmSSnXyD45QYMM1oI6Mwj6sbc/diiOCo/wMVraF6 qveY1hnACKv1An5XpOOo4X4rOXw8towaw5xK5yDCS9Uhbip/H+LxZogg0Ui2l08m13I8 ApLg== X-Gm-Message-State: ANhLgQ0unlUXef0ktyzVmxIDb9jq87TBCmzOZoLRRkgS3aTUBNpBS4kA aSyokulD4rFR/oFiOxIMqfMuVA== X-Google-Smtp-Source: ADFU+vsM+Vfpms3zXqE0iTdEACgBZZKThffCnsSkWXMghC/ISuGvrMn0lyiEyraw5pdMoY2oKXYF2A== X-Received: by 2002:a37:b981:: with SMTP id j123mr5212765qkf.32.1585672290458; Tue, 31 Mar 2020 09:31:30 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.95.18.252]) by smtp.gmail.com with ESMTPSA id q44sm14399124qtq.11.2020.03.31.09.31.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2020 09:31:29 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id EEA473009FE; Tue, 31 Mar 2020 13:31:26 -0300 (-03) Date: Tue, 31 Mar 2020 13:31:26 -0300 From: Alvaro Herrera To: James Coleman Cc: Tomas Vondra , Michael Paquier , Rafia Sabih , Peter Geoghegan , Simon Riggs , Shaun Thomas , Dmitry Dolgov <9erthalion6@gmail.com>, Alexander Korotkov , Tom Lane , PostgreSQL Developers , Andreas Karlsson Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort) Message-ID: <20200331163126.GA6532@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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