From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | amit(dot)kapila16(at)gmail(dot)com |
Cc: | k(dot)jamison(at)fujitsu(dot)com, tsunakawa(dot)takay(at)fujitsu(dot)com, andres(at)anarazel(dot)de, tgl(at)sss(dot)pgh(dot)pa(dot)us, thomas(dot)munro(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, tomas(dot)vondra(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Patch] Optimize dropping of relation buffers using dlist |
Date: | 2020-12-08 00:45:53 |
Message-ID: | 20201208.094553.2234452041399170218.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Mon, 7 Dec 2020 17:18:31 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> On Mon, Dec 7, 2020 at 12:32 PM k(dot)jamison(at)fujitsu(dot)com
> <k(dot)jamison(at)fujitsu(dot)com> wrote:
> >
> > On Friday, December 4, 2020 8:27 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > Hi,
> > I have reported before that it is not always the case that the "cached" flag of
> > srnblocks() return true. So when I checked the truncate test case used in my
> > patch, it does not enter the optimization path despite doing INSERT before
> > truncation of table.
> > The reason for that is because in TRUNCATE, a new RelFileNode is assigned
> > to the relation when creating a new file. In recovery, XLogReadBufferExtended()
> > always opens the RelFileNode and calls smgrnblocks() for that RelFileNode for the
> > first time. And for recovery processing, different RelFileNodes are used for the
> > INSERTs to the table and TRUNCATE to the same table.
> >
>
> Hmm, how is it possible if Insert is done before Truncate? The insert
> should happen in old RelFileNode only. I have verified by adding a
> break-in (while (1), so that it stops there) heap_xlog_insert and
> DropRelFileNodesAllBuffers(), and both get the same (old) RelFileNode.
> How have you verified what you are saying?
You might be thinking of in-transaction sequence of
Inert-truncate. What *I* mention before is truncation of a relation
that smgrnblocks() has already been called for. The most common way
to make it happen was INSERTs *before* the truncating transaction
starts. It may be a SELECT on a hot-standby. Sorry for the confusing
expression.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-12-08 00:53:14 | Re: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | Alexander Korotkov | 2020-12-08 00:20:10 | Re: range_agg |