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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Дата
Msg-id CAA4eK1+pQcCW6miuZ0w6fw9=Wx7SrkHY=k4V4op4wmwevLMGbQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Unhappy about API changes in the no-fsm-for-small-rels patch  (Andres Freund <andres@anarazel.de>)
Ответы Re: Unhappy about API changes in the no-fsm-for-small-rels patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, May 6, 2019 at 8:57 PM Andres Freund <andres@anarazel.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: standby recovery fails (tablespace related) (tentative patchand discussion)