On Mon, Jan 17, 2022 at 8:39 PM James Coleman <jtc331@gmail.com> wrote:
> I wondered about that, but commit_ts already does more than commit
> timestamps by recording the xid of the last commit.
Well, if you're maintaining an SLRU, you do kind of need to know where
the leading and lagging ends are.
> For that matter, keeping a cache of last commit metadata in shared
> memory is arguably not obviously implied by "track_commit_timestamps",
> which leads to the below...
I suppose that's true in the strictest sense, but tracking information
does seem to imply having a way to look it up.
> I'm curious, though: I realize it's in the hot path, and I realize
> that there's an accretive cost to even small features, but given we're
> already paying the lock cost and updating memory in what is presumably
> the same cache line, would you expect this cost to be clearly
> measurable?
If you'd asked me ten years ago, I would have said "no, can't matter,"
but Andres has subsequently demonstrated that a lot of things that I
thought were well-optimized were actually able to be optimized a lot
better than I thought possible, and some of them were in this area.
Still, I think it's unlikely that your patch would have a measurable
effect for the reasons that you state. Wouldn't hurt to test, though.
As far as performance goes, I'm more concerned about Alvaro's patch.
My concern with this one is more around whether it's too much of a
kludge.
--
Robert Haas
EDB: http://www.enterprisedb.com