From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
Date: | 2019-03-29 16:20:54 |
Message-ID: | CANP8+jLMd_aexQbZ3y0oiq0sWZcR7S_Ks2KnaMBbrEnKwKHF0Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Fri, 29 Mar 2019 at 16:12, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2019-03-29 15:58:14 +0000, Simon Riggs wrote:
> > On Fri, 29 Mar 2019 at 15:29, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > That's far from a trivial feature imo. It seems quite possible that
> we'd
> > > end up with increased overhead, because the current logic can get away
> > > with only doing hint bit style writes - but would that be true if we
> > > started actually replacing the item pointers? Because I don't see any
> > > guarantee they couldn't cross a page boundary etc? So I think we'd need
> > > to do WAL logging during index searches, which seems prohibitively
> > > expensive.
> > >
> >
> > Don't see that.
> >
> > I was talking about reusing the first 4 bytes of an index tuple's
> > ItemPointerData,
> > which is the first field of an index tuple. Index tuples are MAXALIGNed,
> so
> > I can't see how that would ever cross a page boundary.
>
> They're 8 bytes, and MAXALIGN often is 4 bytes:
>
xids are 4 bytes, so we're good.
If MAXALIGN could ever be 2 bytes, we'd have a problem.
So as a whole they definitely can cross sector boundaries. You might be
> able to argue your way out of that by saying that the blkid is going to
> be aligned, but that's not that trivial, as t_info isn't guaranteed
> that.
>
> But even so, you can't have unlogged changes that you then rely on. Even
> if there's no torn page issue. Currently BTP_HAS_GARBAGE and
> ItemIdMarkDead() are treated as hints - if we want to guarantee all
> these are accurate, I don't quite see how we'd get around WAL logging
> those.
>
You can have unlogged changes that you rely on - that is exactly how hints
work.
If the hint is lost, we do the I/O. Worst case it would be the same as what
you have now.
I'm talking about saving many I/Os - this doesn't need to provably avoid
all I/Os to work, its incremental benefit all the way.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-03-29 16:21:27 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
Previous Message | Andres Freund | 2019-03-29 16:12:38 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-03-29 16:21:27 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
Previous Message | Andres Freund | 2019-03-29 16:12:38 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |