From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | tsunakawa(dot)takay(at)fujitsu(dot)com |
Cc: | k(dot)jamison(at)fujitsu(dot)com, andres(at)anarazel(dot)de, amit(dot)kapila16(at)gmail(dot)com, 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-04 05:28:14 |
Message-ID: | 20201204.142814.1105517244443403085.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 3 Dec 2020 07:18:16 +0000, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote in
> From: Jamison, Kirk/ジャミソン カーク <k(dot)jamison(at)fujitsu(dot)com>
> > Apologies for the delay, but attached are the updated versions to simplify the
> > patches.
>
> Looks good for me. Thanks to Horiguchi-san and Andres-san, the code bebecame further compact and easier to read. I've marked this ready for committer.
>
>
> To the committer:
> I don't think it's necessary to refer to COMMIT/ROLLBACK PREPARED in the following part of the 0003 commit message. They surely call DropRelFileNodesAllBuffers(), but COMMIT/ROLLBACK also call it.
>
> the full scan threshold. This improves the DropRelationFiles()
> performance when the TRUNCATE command truncated off any of the empty
> pages at the end of relation, and when dropping relation buffers if a
> commit/rollback transaction has been prepared in FinishPreparedTransaction().
I think whether we can use this optimization only by looking
InRecovery is still in doubt. Or if we can decide that on that
criteria, 0003 also can be simplivied using the same assumption.
Separate from the maybe-remaining discussion, I have a comment on the
revised code in 0004.
+ * equal to the full scan threshold.
+ */
+ if (nBlocksToInvalidate >= BUF_DROP_FULL_SCAN_THRESHOLD)
+ {
+ pfree(block);
+ goto buffer_full_scan;
+ }
I don't particularily hate goto statement but we can easily avoid that
by reversing the condition here. You might consider the length of the
line calling "FindAndDropRelFileNodeBuffers" but the indentation can
be lowered by inverting the condition on BLockNumberIsValid.
!| if (nBlocksToInvalidate < BUF_DROP_FULL_SCAN_THRESHOLD)
| {
| for (i = 0; i < n; i++)
| {
| /*
| * If block to drop is valid, drop the buffers of the fork.
| * Zero the firstDelBlock because all buffers will be
| * dropped anyway.
| */
| for (j = 0; j <= MAX_FORKNUM; j++)
| {
!| if (!BlockNumberIsValid(block[i][j]))
!| continue;
|
| FindAndDropRelFileNodeBuffers(smgr_reln[i]->smgr_rnode.node,
| j, block[i][j], 0);
| }
| }
| pfree(block);
| return;
| }
|
| pfree(block);
Or we can separate the calcualtion part and the execution part by
introducing a flag "do_fullscan".
| /*
| * We enter the optimization iff we are in recovery. Otherwise,
| * we proceed to full scan of the whole buffer pool.
| */
| if (InRecovery)
| {
...
!| if (nBlocksToInvalidate < BUF_DROP_FULL_SCAN_THRESHOLD)
!| do_fullscan = false;
!| }
!|
!| if (!do_fullscan)
!| {
| for (i = 0; i < n; i++)
| {
| /*
| * If block to drop is valid, drop the buffers of the fork.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-12-04 05:29:35 | Re: Is it useful to record whether plans are generic or custom? |
Previous Message | Amit Kapila | 2020-12-04 05:05:15 | Re: Single transaction in the tablesync worker? |