Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gzny1-0005TW-BK for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Mar 2019 19:37:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gzny0-0000yb-1d for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Mar 2019 19:37:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gznx2-0004jk-8A for pgsql-hackers@lists.postgresql.org; Fri, 01 Mar 2019 19:36:08 +0000 Received: from smtp-fw-4101.amazon.com ([72.21.198.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gznwz-00051c-TB for pgsql-hackers@postgresql.org; Fri, 01 Mar 2019 19:36:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1551468965; x=1583004965; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Sx7LlxLWxFPPX040kZD8cNfNPXuuaR6p4lXw5Zl/j4Y=; b=Io++IUSfAkpiJ19HVYUdlwkja+GmfNIEZxNnwtnWW2c5y86Xnwb1CHCr IXl9Uv0h+n92pb+TO++p1FwXDFpFsu0pDTYM8aRSKNnngm+dybAAv2uuI oh6et1TAkaAwW5+QmehwyCGhmc7qhrLWM8i0x+ukKiXnh+nbjchErcIR+ E=; X-IronPort-AV: E=Sophos;i="5.58,428,1544486400"; d="scan'208";a="761312519" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-67b371d8.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Mar 2019 19:36:02 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-67b371d8.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id x21JZwgV045954 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Mar 2019 19:36:01 GMT Received: from EX13D05UWC002.ant.amazon.com (10.43.162.92) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 1 Mar 2019 19:36:01 +0000 Received: from f01898859afd.ant.amazon.com (10.43.162.142) by EX13D05UWC002.ant.amazon.com (10.43.162.92) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 1 Mar 2019 19:36:00 +0000 Date: Fri, 1 Mar 2019 11:35:58 -0800 From: Shawn Debnath To: Robert Haas CC: Andres Freund , Thomas Munro , Thomas Munro , Dmitry Dolgov <9erthalion6@gmail.com>, PostgreSQL-development Subject: Re: Refactoring the checkpointer's fsync request queue Message-ID: <20190301193558.GA4664@f01898859afd.ant.amazon.com> References: <20190222224853.ahvm3bf52zqr7k7h@alap3.anarazel.de> <20190222230916.5mfsqn3oesd2nxiz@alap3.anarazel.de> <20190222234549.GA7397@f01898859afd.ant.amazon.com> <20190222235742.4oed46wocpjfpoa5@alap3.anarazel.de> <20190227212653.GA7171@f01898859afd.ant.amazon.com> <20190301174256.3um2t73wycsywrur@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Originating-IP: [10.43.162.142] X-ClientProxiedBy: EX13D11UWC003.ant.amazon.com (10.43.162.162) To EX13D05UWC002.ant.amazon.com (10.43.162.92) Precedence: Bulk List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Mar 01, 2019 at 01:15:21PM -0500, Robert Haas wrote: > > > > > > +typedef enum syncrequestowner > > > +{ > > > + SYNC_MD = 0 /* md smgr */ > > > +} syncrequestowner; > > > > > > I have a feeling that Andres wanted to see a single enum combining > > > both the "operation" and the "owner", like SYNC_REQ_CANCEL_MD, > > > SYNC_REQ_CANCEL_UNDO, ... but I actually like it better the way you > > > have it. > > > > Obviously it's nicer looking this way, but OTOH, that means we have to > > send more data over the queue, because we can't easily combine the > > request + "owner". I don't have too strong feelings about it though. > > Yeah, I would lean toward combining those. I disagree, at least with combining and retaining enums. Encoding all the possible request types with the current, planned and future SMGRs would cause a sheer explosion in the number of enum values. Not to mention that you have multiple enum values for the same behavior - which just isn't clean. And handling of these enums in the code would be ugly too. Do note that these are typedef'ed to uint8 currently. For a default config with 128 MB shared_buffers, we will use an extra 16kB (one extra byte to represent the owner). I am hesitant to change this right now unless folks feel strongly about it. If so, I would combine the type and owner by splitting it up in 4 bit chunks, allowing for 16 request types and 16 smgrs. This change would only apply for the in-memory queue. The code and functions would continue using the enums. -- Shawn Debnath Amazon Web Services (AWS)