On Mon, 10 Aug 2020 at 23:56, Alvaro Herrera wrote:
>
> The problem was simply that when a page is
> examined by a seqscan, we do HeapTupleSatisfiesVisibility of each tuple
> in isolation; and for each tuple we call SetHintBits(). And only the
> first time the FPI happens; by the time we get to t
On Wed, 12 Aug 2020 at 02:42, Alvaro Herrera wrote:
>
> On 2020-Aug-11, Masahiko Sawada wrote:
>
> > On Tue, 11 Aug 2020 at 07:56, Alvaro Herrera
> > wrote:
>
> > > So if you have some table where tuples gain hint bits in bulk, and
> > > rarely modify the pages afterwards, and promote before tho
On 2020-Aug-11, Masahiko Sawada wrote:
> On Tue, 11 Aug 2020 at 07:56, Alvaro Herrera wrote:
> > So if you have some table where tuples gain hint bits in bulk, and
> > rarely modify the pages afterwards, and promote before those pages are
> > frozen, then you may end up with a massive amount of
On Tue, Aug 11, 2020 at 2:55 AM Masahiko Sawada
wrote:
>
> On Tue, 11 Aug 2020 at 07:56, Alvaro Herrera wrote:
> >
> > Last week, James reported to us that after promoting a replica, some
> > seqscan was taking a huge amount of time; on investigation he saw that
> > there was a high rate of FPI_F
On Tue, 11 Aug 2020 at 07:56, Alvaro Herrera wrote:
>
> Last week, James reported to us that after promoting a replica, some
> seqscan was taking a huge amount of time; on investigation he saw that
> there was a high rate of FPI_FOR_HINT wal messages by the seqscan.
> Looking closely at the genera
Last week, James reported to us that after promoting a replica, some
seqscan was taking a huge amount of time; on investigation he saw that
there was a high rate of FPI_FOR_HINT wal messages by the seqscan.
Looking closely at the generated traffic, HEAP_XMIN_COMMITTED was being
set on some tuples.
