Re: Unhappy about API changes in the no-fsm-for-small-rels patch

Hi,

On 2019-04-16 14:31:25 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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