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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Date: 2019-05-07 06:07:25
Message-ID: CAA4eK1+pQcCW6miuZ0w6fw9=Wx7SrkHY=k4V4op4wmwevLMGbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 6, 2019 at 8:57 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2019-05-06 11:10:15 -0400, Robert Haas wrote:
>
> > I think it's legitimate to question whether sending additional
> > invalidation messages as part of the design of this feature is a good
> > idea. If it happens frequently, it could trigger expensive sinval
> > resets more often. I don't understand the various proposals well
> > enough to know whether that's really a problem, but if you've got a
> > lot of relations for which this optimization is in use, I'm not sure I
> > see why it couldn't be.
>
> I don't think it's an actual problem. We'd only do so when creating an
> FSM, or when freeing up additional space that'd otherwise not be visible
> to other backends.
>

The other place we need to consider for this is when one of the
backends updates its map (due to unavailability of space in the
existing set of pages). We can choose not to send invalidation in
this case, but then different backends need to identify the same thing
themselves and reconstruct the map again.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2019-05-07 06:47:11 Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Previous Message Masahiko Sawada 2019-05-07 06:04:14 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)