On Mon, Jan 22, 2024 at 5:38 AM Aleksander Alekseev <aleksan...@timescale.com> wrote: > I don't think that closing CF entries purely due to inactivity is a > good practice (neither something we did before) as long as there is > code, it applies, etc. There are a lot of patches and few people > working on them. Inactivity in a given thread doesn't necessarily > indicate lack of interest, more likely lack of resources.
If the CF entry doesn't serve the purpose of allowing someone to find patches in need of review, it's worse than useless. Patches that aren't getting reviewed should stay in the CF until they do, or until we make a collective decision that we don't care about or want that particular patch enough to bother. But patches that are not ready for review need to get out until such time as they are. Otherwise they're just non-actionable clutter. And unfortunately we have so much of that in the CF app now that finding things that really need review is time consuming and difficult. That REALLY needs to be cleaned up. In the case of this particular patch, I think the problem is that there's no consensus on the design. There's not a ton of debate on this thread, but thread [1] linked in the original post contains a lot of vigorous debate about what the right thing to do is here and I don't believe we reached any meeting of the minds. In light of that lack of agreement, I'm honestly a bit confused why Matthias even found it worthwhile to submit this on a new thread. I think we all agree with him that there's room for improvement here, but we don't agree on what particular form that improvement should take, and as long as that agreement is lacking, I find it hard to imagine anything getting committed. The task right now is to get agreement on something, and leaving the CF entry open longer isn't going make the people who have already expressed opinions start agreeing with each other more than they do already. It looks like I never replied to https://www.postgresql.org/message-id/20221019192130.ebjbycpw6bzjry4v%40awork3.anarazel.de but, FWIW, I agree with Andres that applying the same technique to multiple fields that are stored together (DB OID, TS OID, rel #, block #) is unlikely in practice to produce many cases that regress. But the question for this thread is really more about whether we're OK with using ad-hoc bit swizzling to reduce the size of xlog records or whether we want to insist on the use of a uniform varint encoding. Heikki and Andres both seem to favor the latter. IIRC, I was initially more optimistic about ad-hoc bit swizzling being a potentially acceptable technique, but I'm not convinced enough about it to argue against two very smart committers both of whom know more about micro-optimizing performance than I do, and nobody else seems to making this argument on this thread either, so I just don't really see how this patch is ever going to go anywhere in its current form. -- Robert Haas EDB: http://www.enterprisedb.com