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 TYAPR01MB299039415F7A87F46501F83EFECD0@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: [Patch] Optimize dropping of relation buffers using dlist  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
Responses Re: [Patch] Optimize dropping of relation buffers using dlist
List pgsql-hackers
From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> Because one of the rel's cached value was false, it forced the
> full-scan path for TRUNCATE.
> Is there a possible workaround for this?

Hmm, the other two relfilenodes are for the TOAST table and index of the target table.  I think the INSERT didn't
accessthose TOAST relfilenodes because the inserted data was stored in the main storage.  But TRUNCATE always truncates
allthe three relfilenodes.  So, the standby had not opened the relfilenode for the TOAST stuff or cached its size when
replayingthe TRUNCATE.
 

I'm afraid this is more common than we can ignore and accept the slow traditional path, but I don't think of a good
ideato use the cached flag.
 


Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: PG vs LLVM 12 on seawasp, next round
Next
From: Andres Freund
Date:
Subject: Re: Blocking I/O, async I/O and io_uring