Re: GUC for cleanup indexes threshold.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>
Subject: Re: GUC for cleanup indexes threshold.
Date: 2017-02-26 06:51:53
Message-ID: CA+TgmoZ9G1x=MvKmuy6XrfqPz==RBG5VBe5hsNcQuo=PNZSNog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 25, 2017 at 3:40 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Fri, Feb 24, 2017 at 9:26 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-02-26 07:15:30 Re: UPDATE of partition key
Previous Message Robert Haas 2017-02-26 06:41:41 Re: Making clausesel.c Smarter