Re: opportunistic tuple freezing

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: opportunistic tuple freezing
Дата
Msg-id 603c8f070909170936j35c52085q6a1f3fa2827f6db0@mail.gmail.com
обсуждение исходный текст
Ответ на Re: opportunistic tuple freezing  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: opportunistic tuple freezing  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On Thu, Sep 17, 2009 at 12:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> Does the community think that experimental performance testing is a
>> must-have in order for this patch to be acceptable?
>
> Dunno about others, but I think so.  It's complicating both the
> implementation and the users-eye view of VACUUM, and I want more than
> a hypothesis that we're going to get something useful out of that.
>
> If we can't test it in a reasonable time frame for this commitfest,
> then we should move it to the queue for the next one.

Despite my recent screw-up in this department, it should really be the
patch author's responsibility to test the patch first.  Then the
reviewing process can involve additional testing.  So I would say this
should be moved to Returned With Feedback, and then it can be
resubmitted later with test results.

The problem with bumping things to the next CommitFest is that it then
becomes the CommitFest management team's problem to sort out which
patches were bumped but the necessary to-do items weren't completed,
versus being the patch author's problem to let us know when they have
completed the necessary to-do items.

So I am in favor of a policy that things should only be moved to the
next CommitFest when they have ALREADY satisfied the requirements for
being reviewed during that CommitFest.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Feedback on getting rid of VACUUM FULL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Feedback on getting rid of VACUUM FULL