Re: [PoC] Non-volatile WAL buffer
От | Amit Langote |
---|---|
Тема | Re: [PoC] Non-volatile WAL buffer |
Дата | |
Msg-id | CA+HiwqGG_1DEKJwW1fvPK_8HjuY3zfNR6Th2Tj7H0ZLtFDXLPQ@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: [PoC] Non-volatile WAL buffer (Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp>) |
Ответы |
RE: [PoC] Non-volatile WAL buffer
|
Список | pgsql-hackers |
Hello, On Mon, Feb 17, 2020 at 4:16 PM Takashi Menjo <takashi.menjou.vg@hco.ntt.co.jp> wrote: > Hello Amit, > > > I apologize for not having any opinion on the patches themselves, but let me point out that it's better to base these > > patches on HEAD (master branch) than REL_12_0, because all new code is committed to the master branch, > > whereas stable branches such as REL_12_0 only receive bug fixes. Do you have any specific reason to be working > > on REL_12_0? > > Yes, because I think it's human-friendly to reproduce and discuss performance measurement. Of course I know all new acceptedpatches are merged into master's HEAD, not stable branches and not even release tags, so I'm aware of rebasing mypatchset onto master sooner or later. However, if someone, including me, says that s/he applies my patchset to "master"and measures its performance, we have to pay attention to which commit the "master" really points to. Although wehave sha1 hashes to specify which commit, we should check whether the specific commit on master has patches affecting performanceor not because master's HEAD gets new patches day by day. On the other hand, a release tag clearly points thecommit all we probably know. Also we can check more easily the features and improvements by using release notes and usermanuals. Thanks for clarifying. I see where you're coming from. While I do sometimes see people reporting numbers with the latest stable release' branch, that's normally just one of the baselines. The more important baseline for ongoing development is the master branch's HEAD, which is also what people volunteering to test your patches would use. Anyone who reports would have to give at least two numbers -- performance with a branch's HEAD without patch applied and that with patch applied -- which can be enough in most cases to see the difference the patch makes. Sure, the numbers might change on each report, but that's fine I'd think. If you continue to develop against the stable branch, you might miss to notice impact from any relevant developments in the master branch, even developments which possibly require rethinking the architecture of your own changes, although maybe that rarely occurs. Thanks, Amit
В списке pgsql-hackers по дате отправления: