Hi, On 2019-04-16 14:31:25 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I'm kinda thinking that this is the wrong architecture. > > The bits of that patch that I've looked at seemed like a mess > to me too. AFAICT, it's trying to use a single global "map" > for all relations (strike 1) without any clear tracking of > which relation the map currently describes (strike 2).
Well, strike 2 basically is not a problem right now, because the map is cleared whenever a search for a target buffer succeeded. But that has pretty obvious efficiency issues... > This can only work at all if an inaccurate map is very fail-soft, > which I'm not convinced it is I think it better needs to be fail-soft independent of this the no-fsm patch. Because the fsm is not WAL logged etc, it's pretty easy to get a pretty corrupted version. And we better deal with that. > and in any case it seems pretty inefficient for workloads that insert > into multiple tables. As is, it's inefficient for insertions into a *single* relation. The RelationGetTargetBlock() makes it not crazily expensive, but it's still plenty expensive. > I'd have expected any such map to be per-table and be stored in > the relcache. Same. Greetings, Andres Freund
