Re: opportunistic tuple freezing - Mailing list pgsql-hackers

From Robert Haas
Subject Re: opportunistic tuple freezing
Date
Msg-id 603c8f070909170936j35c52085q6a1f3fa2827f6db0@mail.gmail.com
Whole thread Raw
In response to Re: opportunistic tuple freezing  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: opportunistic tuple freezing
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Feedback on getting rid of VACUUM FULL
Next
From: Tom Lane
Date:
Subject: Re: Feedback on getting rid of VACUUM FULL