Hi,
On 2019-04-16 14:31:25 -0400, Tom Lane wrote:
> Andres Freund <andres@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
