Re: [HACKERS] Proposal : For Auto-Prewarm.
От | Mithun Cy |
---|---|
Тема | Re: [HACKERS] Proposal : For Auto-Prewarm. |
Дата | |
Msg-id | CAD__OuinNvR71GS9D0-S232CZk09PRfBt1S0ye8akDL0-1AAog@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal : For Auto-Prewarm. (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Mon, Jul 3, 2017 at 3:55 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Fri, Jun 23, 2017 at 3:22 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Thu, Jun 15, 2017 at 12:35 AM, Mithun Cy <mithun.cy@enterprisedb.com> wrote: >> >> * Instead of creating our own buffering system via buffer_file_write() >> and buffer_file_flush(), why not just use the facilities provided by >> the operating system? fopen() et. al. provide buffering, and we have >> AllocateFile() to provide a FILE *; it's just like >> OpenTransientFile(), which you are using, but you'll get the buffering >> stuff for free. Maybe there's some reason why this won't work out >> nicely, but off-hand it seems like it might. It looks like you are >> already using AllocateFile() to read the dump, so using it to write >> the dump as well seems like it would be logical. >> > > One thing that is worth considering is AllocateFile is recommended to > be used for short operations. Refer text atop AllocateFile(). If the > number of blocks to be dumped is large, then the file can remain open > for the significant period of time. -- Agree. I think I need suggestion on this we will hold on to 1 fd, but I am not sure what amount of time file being opened qualify as a case against using AllocateFile(). -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: