Re: Eliminating PD_ALL_VISIBLE, take 2

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Eliminating PD_ALL_VISIBLE, take 2
Дата
Msg-id 1372787267.19747.124.camel@jdavis
обсуждение исходный текст
Ответ на Re: Eliminating PD_ALL_VISIBLE, take 2  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Tue, 2013-07-02 at 19:34 +0200, Andres Freund wrote:
> Well, I still have my doubts that it's a good idea to remove this
> knowledge from the page level. And that's not primarily related to
> performance. Unfortunately a good part of judging architectural
> questions is gut feeling...
> The only real argument for the removal I see - removal of one cycle of
> dirtying - wouldn't really weigh much if we would combine it with
> freezing (which we can do if Robert's forensic freezing patch makes it
> in).

I'll have to take a closer look at the relationship between Robert's and
Heikki's proposals.

I have a gut feeling that the complexity we go through to maintain
PD_ALL_VISIBLE is unnecessary and will cause us problems later. If we
could combine freezing and marking all-visible, and use WAL for
PD_ALL_VISIBLE in a normal fashion, then I'd be content with that.

Even better would be if we could eliminate the freeze I/O with Heikki's
proposal, and eliminate the PD_ALL_VISIBLE I/O with my patch. But,
that's easier said than done.

Regards,Jeff Davis





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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Patch: clean up addRangeTableEntryForFunction
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: [9.4 CF 1] The Commitfest Slacker List