Re: GUC values - recommended way to declare the C variables?
От | Michael Paquier |
---|---|
Тема | Re: GUC values - recommended way to declare the C variables? |
Дата | |
Msg-id | Y1tC7RsFfSpP4/4M@paquier.xyz обсуждение исходный текст |
Ответ на | Re: GUC values - recommended way to declare the C variables? (Peter Smith <smithpb2250@gmail.com>) |
Ответы |
Re: GUC values - recommended way to declare the C variables?
Re: GUC values - recommended way to declare the C variables? |
Список | pgsql-hackers |
On Thu, Oct 27, 2022 at 07:00:26PM +1100, Peter Smith wrote: > The GUC defaults of guc_tables.c, and the modified GUC C var > declarations now share the same common #define'd value (instead of > cut/paste preprocessor code). Thanks. I have not looked at the checkup logic yet, but the central declarations seem rather sane, and I have a few comments about the latter. +#ifdef WIN32 +#define DEFAULT_UPDATE_PROCESS_TITLE false +#else +#define DEFAULT_UPDATE_PROCESS_TITLE true +#endif This is the kind of things I would document as a comment, say "Disabled on Windows as the performance overhead can be significant". Actually, pg_iovec.h uses WIN32 without any previous header declared, but win32.h tells a different story as of ed9b3606, where we would define WIN32 if it does not exist yet. That may impact the default depending on the environment used? I am wondering whether the top of win32.h could be removed, these days.. +#ifdef USE_PREFETCH +#define DEFAULT_EFFECTIVE_IO_CONCURRENCY 1 +#define DEFAULT_MAINTENANCE_IO_CONCURRENCY 10 +#else +#define DEFAULT_EFFECTIVE_IO_CONCURRENCY 0 +#define DEFAULT_MAINTENANCE_IO_CONCURRENCY 0 +#endif These don't make sense without prefetching available. Perhaps that's obvious enough when reading the code still I would add a small note. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: