Re: [HACKERS] GUC for cleanup indexes threshold.

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] GUC for cleanup indexes threshold.
Дата
Msg-id CA+TgmoZ9G1x=MvKmuy6XrfqPz==RBG5VBe5hsNcQuo=PNZSNog@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GUC for cleanup indexes threshold.  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: [HACKERS] GUC for cleanup indexes threshold.  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Sat, Feb 25, 2017 at 3:40 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> On Fri, Feb 24, 2017 at 9:26 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I think this thread is pretty short on evidence that would let us make
>> a smart decision about what to do here.  I see three possibilities.
>> The first is that this patch is a good idea whether we do something
>> about the issue of half-dead pages or not.  The second is that this
>> patch is a good idea if we do something about the issue of half-dead
>> pages but a bad idea if we don't.  The third is that this patch is a
>> bad idea whether or not we do anything about the issue of half-dead
>> pages.
>
> Half-dead pages are not really relevant to this discussion, AFAICT. I
> think that both you and Simon mean "recyclable" pages. There are
> several levels of indirection involved here, to keep the locking very
> granular, so it gets tricky to talk about.

Thanks for the clarification.  I wasn't very clear on what was going
on here; that helps.

The thing that strikes me based on what you wrote is that our page
recycling seems to admit of long delays even as things stand.  There's
no bound on how much time could pass between one index vacuum and the
next, and RecentGlobalXmin could and probably usually will advance
past the point that would allow recycling long before the next index
vacuum cycle.  I don't know whether that strengthens or weakens
Simon's argument.  On the one hand, you could argue that if we're
already doing this on a long delay, making it even longer probably
won't hurt much.  On the other hand, you could argue that if the
current situation is bad, we should at least avoid making it worse.  I
don't know which of those arguments is correct, if either.  Do you
have an idea about that, or any ideas for experiments we could try?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Making clausesel.c Smarter
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key