Hi, On 2018-01-03 21:43:51 +0100, Remi Colinet wrote: > - we may test different combinations of file and block sizes, for the > relation and the WAL in order to have the better performances of the server. > Avoiding a compilation for each combination of values seems to make sense.
That's something you need to proof to beneficial *before* we make this change. > - Selecting the correct values for file and block sizes is a DBA task, and > not a developer task. > For instance, when someone wants to create a Linux filesystem with a given > block size, he is not forced to accept a given value chosed by the > developer of the filesystem driver when this later was compiled. I'm unconvinced there's as much value syncing up fs in pg as some conventional wisdom says. > - The file and block sizes should depend mostly of the physical server and > physical storage. > Not of the database software itself. Citation needed. > Regarding the cost of using run-time configurable values for file and block > sizes of the WAL and relations, this cost is low both : > > - from a developer point of view: the source code changes are spread in > many files but only a few one have significant changes. > Mainly the tidbitmap.c is concerned the change. Other changes are minor > changes. > > - from a run-time point of view. The overhead is only at the start of the > database instance. > And moreover, the overhead is still very low at the start of the server, > with only a few more dynamic memory allocations. That's to some degree because you rely on stack allocation of variable sided amounts of data - we can't rely on that. E.g. you allocate stack variables sized by rel_block_size, that's unfortunately not ok. Additionally some of the size calculations will have some performance impact. - Andres
