RE: [Patch] Optimize dropping of relation buffers using dlist

From: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
To: 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>, "amit(dot)kapila16(at)gmail(dot)com" <amit(dot)kapila16(at)gmail(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "tomas(dot)vondra(at)2ndquadrant(dot)com" <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist
Date: 2020-10-01 04:20:27
Message-ID: TYAPR01MB2990C3A3C9B64DA634B68C43FE300@TYAPR01MB2990.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
> In more detail, if smgrcachednblocks() returned InvalidBlockNumber for
> any of the forks, we should give up the optimization at all since we
> need to run a full scan anyway. On the other hand, if any of the
> forks is smaller than the threshold, we still can use the optimization
> when we know the accurate block number of all the forks.

Ah, I got your point (many eyes in open source development is nice.) Still, I feel it's better to treat each fork separately, because the inner loop in the traditional path may be able to skip forks that have been already processed in the optimization path. For example, if the forks[] array contains {fsm, vm, main} in this order (I know main is usually put at the beginning), fsm and vm are processed in the optimization path and the inner loop in the traditional path can skip fsm and vm.

> Still, I prefer to use total block number of all forks since we anyway
> visit the all forks. Is there any reason to exlucde forks other than
> the main fork while we visit all of them already?

When the number of cached blocks for a main fork is below the threshold but the total cached blocks of all forks exceeds the threshold, the optimization is skipped. I think it's mottainai.

Regards
Takayuki Tsunakawa

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-10-01 04:32:20 Re: making update/delete of inheritance trees scale better
Previous Message Dilip Kumar 2020-10-01 04:18:39 Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables