On Sat, Mar 2, 2019 at 9:35 AM Shawn Debnath <s...@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 <s...@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.
It's not so much the "explosion" that bothers me. I think we should have a distinct sync requester enum, because we need a way to index into the table of callbacks. How exactly you pack the two enums into compact space seems like a separate question; doing it with two words would obviously be wasteful, but it should be possible stuff them into (say) a single uint8_t, uint16_t or whatever will pack nicely in the request struct and allow the full range of request types (4?) + the full range of sync requesters (which we propose to expand to 3 in the forseeable future). Now perhaps the single enum idea was going to involve explicit values that encode the two values SYNC_REQ_CANCEL_MD = 0x1 | (0x04 << 4) so you could still extract the requester part, but that's just the same thing with uglier code. -- Thomas Munro https://enterprisedb.com
