On Wed, Jan 3, 2018 at 12:26 AM, Robert Haas wrote:
> On Sun, Dec 31, 2017 at 12:00 PM, Remi Colinet
> wrote:
> > Below patch makes block and file sizes defined at cluster creation for
> both
> > the WAL and the relations. This avoids having different server builds for
> > each possible combinat
On Fri, Jan 5, 2018 at 7:54 AM, Michael Paquier
wrote:
> On Fri, Jan 5, 2018 at 9:42 PM, Robert Haas wrote:
>> - run make check-world at all the supposedly-supported block sizes and
>> see if it passes.
>
> Last time I tried that with a 16kB-size block, which was some months
> back, make check co
On Fri, Jan 5, 2018 at 9:42 PM, Robert Haas wrote:
> - run make check-world at all the supposedly-supported block sizes and
> see if it passes.
Last time I tried that with a 16kB-size block, which was some months
back, make check complained about some plan inconsistencies. Perhaps
that's somethin
On Thu, Jan 4, 2018 at 5:15 PM, Remi Colinet wrote:
> Block size does not boils down only to performance.
>
> For instance, having a larger block size allows:
> - to avoid toasting tuples. Rows with sizes larger that the default block
> size can justify larger block sizes.
> - to reduce fragmentat
On Wed, January 3, 2018 4:04 pm, Robert Haas wrote:
> On Wed, Jan 3, 2018 at 3:43 PM, Remi Colinet
> wrote:
>> Justifications are:
>
> I think this is all missing the point. If varying the block size (or
> whatever) is beneficial, then having it configurable at initdb is
> clearly useful. But,
2018-01-03 22:04 GMT+01:00 Robert Haas :
> On Wed, Jan 3, 2018 at 3:43 PM, Remi Colinet
> wrote:
> > Justifications are:
>
> I think this is all missing the point. If varying the block size (or
> whatever) is beneficial, then having it configurable at initdb is
> clearly useful. But, as Andres
Hello,
2018-01-03 21:51 GMT+01:00 Andres Freund :
> 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
On Wed, Jan 3, 2018 at 3:43 PM, Remi Colinet wrote:
> Justifications are:
I think this is all missing the point. If varying the block size (or
whatever) is beneficial, then having it configurable at initdb is
clearly useful. But, as Andres says, you haven't submitted any
evidence that this is t
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 somethin
Robert,
Justifications are:
- 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.
- the same binary can be used on the same host
On Sun, Dec 31, 2017 at 12:00 PM, Remi Colinet wrote:
> Below patch makes block and file sizes defined at cluster creation for both
> the WAL and the relations. This avoids having different server builds for
> each possible combination of block size and file sizes.\
The email thread where we disc
11 matches
Mail list logo
