From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: increasing the default WAL segment size |
Date: | 2017-04-06 23:07:33 |
Message-ID: | 0632f141-80bf-9ca6-4b75-588c1e90ebb6@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/6/17 6:52 PM, Tomas Vondra wrote:
> On 04/06/2017 11:45 PM, David Steele wrote:
>>
>> How many people in the field are running custom builds of
>> Postgres? And of those, how many have changed the WAL segment size?
>> I've never encountered a non-standard segment size or talked to anyone
>> who has. I'm not saying it has *never* happened but I would venture to
>> say it's rare.
>
> I agree it's rare, but I don't think that means we can just consider the
> option as 'unsupported'. We're even mentioning it in the docs as a valid
> way to customize granularity of the WAL archival.
>
> I certainly know people who run custom builds, and some of them run with
> custom WAL segment size. Some of them are our customers, some are not.
> And yes, some of them actually patched the code to allow 256MB WAL
> segments.
I feel a little better knowing that *somebody* is doing it in the field.
>> Just because we don't change the default doesn't mean that others won't.
>> I still think testing for sizes other than 16MB is severely lacking and
>> I don't believe caveat emptor is the way to go.
>
> Aren't you mixing regression and performance testing? I agree we need to
> be sure all segment sizes are handled correctly, no argument here.
Not intentionally. Our standard test suite is only regression as far as
I can see. All the performance testing I've seen has been done ad hoc.
>> I don't have plans to add animals. I think we'd need a way to tell
>> 'make check' to use a different segment size for tests and then
>> hopefully reconfigure some of the existing animals.
>
> OK. My point was that we don't have that capability now, and the latest
> patch is not adding it either.
Agreed.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-04-06 23:14:22 | Re: [COMMITTERS] pgsql: Collect and use multi-column dependency stats |
Previous Message | Tom Lane | 2017-04-06 23:01:32 | Re: Time to change pg_regress diffs to unified by default? |