On 2013-01-09 22:23:25 +0900, Michael Paquier wrote:
> On Wed, Jan 9, 2013 at 9:54 PM, Magnus Hagander <magnus@hagander.net> wrote:
>
> > On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund <andres@2ndquadrant.com>
> > wrote:
> >
> Yeah, so far it's also just my opinion in the other direction :)
> > Hopefully, some others will have thoughts about it too.
> >
> Just giving my 2c here...
>
> Instead of posting multiple 5~7 patches at the same time, why not limiting
> the number of patches published at the same time to a lower number (max
> 2~3)?
I tried to do this. ilist, binaryheap and this this thread... ;)
> The logical replication implementation can be surely broken down into
> many more pieces that could be reviewed carefully one by one, and in a way
> that would make the implementation steps clearer than it is now for all the
> people of this ML.
I don't really see any additional useful splits from the ones made last
round. The relfilenode stuff could be submitted separately but thats
about it and its seemingly not all that useful itself (I personally want
the (tablespace, relfilenode) => reloid mapping function independently,
but I seem to be alone). Its hard to get useful review for patches which
don't have a patch using the facility nearby in my experience.
Where do you see a useful split?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services