RE: [Patch] Optimize dropping of relation buffers using dlist
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | TYAPR01MB299039415F7A87F46501F83EFECD0@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: [Patch] Optimize dropping of relation buffers using dlist ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>) |
Ответы |
Re: [Patch] Optimize dropping of relation buffers using dlist
|
Список | 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 по дате отправления: