Re: xid wraparound danger due to INDEX_CLEANUP false - Mailing list pgsql-hackers

From Robert Haas
Subject Re: xid wraparound danger due to INDEX_CLEANUP false
Date
Msg-id CA+TgmoYrgu09NpM8jsiJJXWfkQooZgQzbvOZvAHxT9M+vV6kTQ@mail.gmail.com
Whole thread Raw
In response to Re: xid wraparound danger due to INDEX_CLEANUP false  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: xid wraparound danger due to INDEX_CLEANUP false  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Fri, Nov 20, 2020 at 2:37 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Right. Maybe we don't ask the index AMs for discrete yes/no answers.
> Maybe we can ask them for a continuous answer, such as a value between
> 0.0 and 1.0 that represents the urgency/bloat, or something like that.
> And so the final yes/no answer that really does have to be made for
> the table as a whole (does VACUUM do a second pass over the heap to
> make LP_DEAD items into LP_UNUSED items?) can at least consider the
> worst case for each index. And maybe the average case, too.

That's an interesting idea. We should think about the needs of brin
indexes when designing something better than the current system. They
have the interesting property that the heap deciding to change LP_DEAD
to LP_UNUSED doesn't break anything even if nothing's been done to the
index, because they don't store TIDs anyway. So that's an example of
an index AM that might want to do some work to keep performance up,
but it's not actually required. This might be orthogonal to the
0.0-1.0 scale you were thinking about, but it might be good to factor
it into the thinking somehow.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: enable_incremental_sort changes query behavior
Next
From: Tom Lane
Date:
Subject: Re: Strange behavior with polygon and NaN