On Tue, 28 Jun 2022 at 19:18, Matthias van de Meent <boekewurm+postg...@gmail.com> wrote:
> I will be the first to admit that it is quite unlikely to be common > practise, but this workload increases the number of dbOid+spcOid > combinations to 100s (even while using only a single tablespace), Which should still fit nicely in 32bits then. Why does that present a problem to this idea? The reason to mention this now is that it would give more space than 56bit limit being suggested here. I am not opposed to the current patch, just finding ways to remove some objections mentioned by others, if those became blockers. > which in my opinion requires some more thought than just handwaving it > into an smgr array and/or checkpoint records. The idea is that we would store the mapping as an array, with the value in the RelFileNode as the offset in the array. The array would be mostly static, so would cache nicely. For convenience, I imagine that the mapping could be included in WAL in or near the checkpoint record, to ensure that the mapping was available in all backups. -- Simon Riggs http://www.EnterpriseDB.com/
