On Tue, 2012-06-12 at 22:06 -0400, Robert Haas wrote:
> > How much of a savings did we get from PD_ALL_VISIBLE when it was added
> > into the page-at-a-time visibility check?
> >
> > >From 608195a3a3656145a7eec7a47d903bc684011d73:
> >
> > "In addition to the visibility map, there's a new PD_ALL_VISIBLE flag on
> > each heap page, also indicating that all tuples on the page are visible
> > to all transactions. It's important that this flag is kept up-to-date.
> > It is also used to skip visibility tests in sequential scans, which
> > gives a small performance gain on seqscans."
> >
> > If "small" means that it's something we can give up, then focusing on
> > HEAP_XMIN_COMMITTED makes sense. But if we can't give it up, then we
> > need to take it into account in the proposal.
>
> It's significant.
In that case, the proposals that only involve HEAP_XMIN_COMMITTED don't
seem viable to me. To get maxiumum read speed, we will need to set
PD_ALL_VISIBLE also, and that means rewriting the entire table anyway
(for the workload that I'm describing).
However, maybe if we combine the approaches, readers could ignore
PD_ALL_VISIBLE during the load, which looks like maybe a 10% penalty,
without having to ignore HEAP_XMIN_COMMITTED (which seems much more
costly to ignore).
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
