Re: SQL/MED estimated time of arrival?

On Sun, Nov 21, 2010 at 10:14 PM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Mon, Nov 22, 2010 at 11:16, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> To have a chance of getting a significant portion
>> of this into PostgreSQL 9.1, it really needs to be broken up into
>> INDEPENDENTLY COMMITTABLE SUB-PATCHES.
>
> Did we discuss about syntax-only patch is not acceptable because
> it makes the head broken state at the previous commit-fest?
> I think that's why the patch becomes so large.

Right, I remember that discussion. Hopefully the distinction between
that conversation and this one is clear.

> So, our guideline to submit a large patch would be:
>  * Split patch into commitable sub-patches (2000 lines each),

It's not a hard number - it's more important that the patch *make
sense* than what the exact line count is. But I think that's a
reasonable guideline to shoot for. Ideally, smaller still would
probably be even better, but sometimes it just can't be done. Also,
note that pulling off small chunks is a valuable way to make progress.
For example, if we notice that there's a 100-line refactoring in the
FDW patch that stands on its own, by all means let's pull it out and
commit it.

>  * But submit a series of patches at once.

When necessary, yes. Of course, the best thing is if you can make
them truly independent and submit the one after another. Get one
committed, move on to the next. But if you can't, then you can't. In
this case, there's not much help for the fact that to decide whether
the FDW patch is a good idea you're probably going to at least want to
glance at the PGFDW and CSVFDW patches -- but it's possible we could
decide to commit the core support first, and then work on getting the
implementations committed afterwards, if we're confident that the
basic design is all right but more work is needed down in the details.

> Am I understanding correctly?

I think so.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company