Date: Mon, 4 Mar 2019 08:55:06 -0800
From: Shawn Debnath <sdn@amazon.com>
To: Robert Haas <robertmhaas@gmail.com>
CC: Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>,
        Thomas Munro <thomas.munro@enterprisedb.com>,
        Dmitry Dolgov
	<9erthalion6@gmail.com>,
        PostgreSQL-development
	<pgsql-hackers@postgresql.org>
Subject: Re: Refactoring the checkpointer's fsync request queue
Message-ID: <20190304165505.GA67539@f01898859afd.ant.amazon.com>
References: <20190222235742.4oed46wocpjfpoa5@alap3.anarazel.de>
 <20190227212653.GA7171@f01898859afd.ant.amazon.com>
 <CA+hUKG+2EuoDhVBdieOKnneFX14SeuRp7z0WG2PSOMJt8ks3qw@mail.gmail.com>
 <CA+hUKGKF7QvUi2ST4R5vd_PVdcztBTXB23ZJwoj_ASoujrbsmQ@mail.gmail.com>
 <20190301174256.3um2t73wycsywrur@alap3.anarazel.de>
 <CA+TgmobqzMkSnWBHcTYqxwQhL3MahX-cpWzs2sVJ4219ciAYGA@mail.gmail.com>
 <20190301193558.GA4664@f01898859afd.ant.amazon.com>
 <CA+Tgmob3hqmNr-EJsudHvFohXKn5wm=Un+nWKXuJiL0fibqhyQ@mail.gmail.com>
 <20190301203533.GB4664@f01898859afd.ant.amazon.com>
 <CA+TgmobdCuF2xNvrL_6H3CzvZsc7nVJbLvd-SL6DSjj++x7trw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmobdCuF2xNvrL_6H3CzvZsc7nVJbLvd-SL6DSjj++x7trw@mail.gmail.com>
User-Agent: Mutt/1.11.3 (2019-02-01)
Precedence: Bulk
Precedence: bulk

On Fri, Mar 01, 2019 at 04:27:47PM -0500, Robert Haas wrote:
> On Fri, Mar 1, 2019 at 3:35 PM Shawn Debnath <sdn@amazon.com> wrote:
> > On Fri, Mar 01, 2019 at 03:03:19PM -0500, Robert Haas wrote:
> > > On Fri, Mar 1, 2019 at 2:36 PM Shawn Debnath <sdn@amazon.com> wrote:
> > > > 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.
> > >
> > > How big of an explosion would it be?
> >
> > 4 enum values x # of smgrs; currently md, soon undo and slru so 12 in
> > total. Any future smgr addition will expand this further.
> 
> I thought the idea was that each smgr might have a different set of
> requests.  If they're all going to have the same set of requests then
> I agree with you.

Yeah, in this particular case and at this layer, the operations are 
consistent across all storage managers, in that, they want to queue a 
new sync request for a specific file, forget an already queued request, 
forget a hierarchy of requests, or unlink a specific file.

The fun is at the smgr layer which was discussed in a sub-thread in the 
"Drop type smgr" thread started by Thomas. I started on a patch and will 
be sending it out after the refactor patch is revised.


-- 
Shawn Debnath
Amazon Web Services (AWS)