Re: [HACKERS] GUC for cleanup indexes threshold. - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] GUC for cleanup indexes threshold.
Date
Msg-id 20180107000220.GX2416@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] GUC for cleanup indexes threshold.  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [HACKERS] GUC for cleanup indexes threshold.
List pgsql-hackers
Greetings Peter,

* Peter Geoghegan (pg@bowt.ie) wrote:
> On Sat, Jan 6, 2018 at 2:20 PM, Stephen Frost <sfrost@snowman.net> wrote:
> >> > IIRC the patches that makes the cleanup scan skip has a problem
> >> > pointed by Peter[1], that is that we stash an XID when a btree page is
> >> > deleted, which is used to determine when it's finally safe to recycle
> >> > the page. Yura's patch doesn't have that problem?
> >> >
> >> > [1]
https://www.postgresql.org/message-id/CAH2-Wz%3D1%3Dt5fcGGfarQGcAWBqaCh%2BdLMjpYCYHpEyzK8Qg6OrQ%40mail.gmail.com
>
> > Masahiko Sawada, if this patch isn't viable or requires serious rework
> > to be acceptable, then perhaps we should change its status to 'returned
> > with feedback' and you can post a new patch for the next commitfest..?
>
> I believe that the problem that I pointed out with freezing/wraparound
> is a solvable problem. If we think about it carefully, we will come up
> with a good solution. I have tried to get the ball rolling with my
> pd_prune_xid suggestion. I think it's important to not lose sight of
> the fact that the page deletion/recycling XID thing is just one detail
> that we need to think about some more.
>
> I cannot fault Sawada-san for waiting to hear other people's views
> before proceeding. It really needs to be properly discussed.

Thanks for commenting!

Perhaps it should really be in Needs review state then..?

Either way, thanks again for the clarification and hopefully this will
revive the discussion.

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] plpgsql - additional extra checks
Next
From: Tom Lane
Date:
Subject: Parallel append plan instability/randomness