Hi, On 2018-08-22 13:35:47 +0500, Andrey Borodin wrote: > > 15 авг. 2018 г., в 2:35, Shawn Debnath <s...@amazon.com> написал(а): > > > > At the Unconference in Ottawa this year, I pitched the idea of moving > > components off of SLRU and on to the buffer cache. The motivation > > behind the idea was three fold: > > > > * Improve performance by eliminating fixed sized caches, simplistic > > scan and eviction algorithms. > > * Ensuring durability and consistency by tracking LSNs and checksums > > per block. > +1, I like this idea more than current patch on CF with checksums for SLRU > pages.
Yea, I don't think it really makes sense to reimplement this logic for SLRUs (and then UNDO) separately. > > 1. Implement a generic block storage manager that parameterizes > > several options like segment sizes, fork and segment naming and > > path schemes, concepts entrenched in md.c that are strongly tied to > > relations. To mitigate risk, I am planning on not modifying md.c > > for the time being. > Probably I'm missing something, but why this should not be in access > methods? I think it's not an absurd idea to put the reserved oid into pg_am (under a separate amtype). Although the fact that shared entries would be in database local tables is a bit weird. But I'm fairly certain that we'd not put any actual data into it, not the least because we need to be able to acess clo etc from connections that cannot attach to a database (say the startup process, which will never ever start reading from a catalog table). So I don't really see what you mean with: > You can extend AM to control it's segment size and ability to > truncate unneeded pages. This may to be useful, for example, in LSM > tree implementation or something similar. that doesn't really seem like it could work. Nor am I even clear what the above points really have to do with the AM layer. Greetings, Andres Freund
