On Thu, May 27, 2021 at 12:46 PM tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com> wrote: > > From: Dilip Kumar <dilipbal...@gmail.com> > Basically you are creating a new table and loading data to it and that means > you will be less likely to access those data soon so for such thing spoiling > buffer cache may not be a good idea. > -------------------------------------------------- > > Some people, including me, would say that the table will be accessed soon and > that's why the data is loaded quickly during minimal maintenance hours. > > > -------------------------------------------------- > I was just suggesting only for experiments for identifying the root cause. > -------------------------------------------------- > > I thought this is a good chance to possibly change things better (^^). > I guess the user would simply think like this: "I just want to finish CTAS as > quickly as possible, so I configured to take advantage of parallelism. I > want CTAS to make most use of our resources. Why doesn't Postgres try to > limit resource usage (by using the ring buffer) against my will?"
If the idea is to give the user control of whether or not to use the separate RING BUFFER for bulk inserts/writes, then how about giving it as a rel option? Currently BAS_BULKWRITE (GetBulkInsertState), is being used by CTAS, Refresh Mat View, Table Rewrites (ATRewriteTable) and COPY. Furthermore, we could make the rel option an integer and allow users to provide the size of the ring buffer they want to choose for a particular bulk insert operation (of course with a max limit which is not exceeding the shared buffers or some reasonable amount not exceeding the RAM of the system). I think we can discuss this in a separate thread and see what other hackers think. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
