From: | Remi Colinet <remi(dot)colinet(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Patch] Make block and file size for WAL and relations defined at cluster creation |
Date: | 2018-01-04 22:15:59 |
Message-ID: | CADdR5nzYfVLo2AyZ+py7mBvivbu-ucGG00=TWkdcBoFXw80Jdg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2018-01-03 22:04 GMT+01:00 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, Jan 3, 2018 at 3:43 PM, Remi Colinet <remi(dot)colinet(at)gmail(dot)com>
> 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 the case. You need to describe scenarios in
> which (1) a non-default blocksize performs better and (2) there's no
> reasonable way to obtain the same performance improvement without
> changing the block size.
>
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 fragmentation in relations.
If changing the block size at initdb is useless, then why allowing
developer to set such block size at compile time?
The patch only allows to shift the block size choice from compilation to
run-time.
Regards
Remi
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jing Wang | 2018-01-04 22:17:12 | Re: Libpq support to connect to standby server as priority |
Previous Message | Thomas Munro | 2018-01-04 22:14:26 | Re: pgsql: Add parallel-aware hash joins. |