RE: [Patch] Optimize dropping of relation buffers using dlist - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: [Patch] Optimize dropping of relation buffers using dlist
Date
Msg-id TYAPR01MB2990C3A3C9B64DA634B68C43FE300@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: [Patch] Optimize dropping of relation buffers using dlist  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: [Patch] Optimize dropping of relation buffers using dlist  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
From: Kyotaro Horiguchi <horikyota.ntt@gmail.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
theoptimization path.  For example, if the forks[] array contains {fsm, vm, main} in this order (I know main is usually
putat the beginning), fsm and vm are processed in the optimization path and the inner loop in the traditional path can
skipfsm 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
exceedsthe threshold, the optimization is skipped.  I think it's mottainai. 


Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Next
From: Michael Paquier
Date:
Subject: Re: making update/delete of inheritance trees scale better