Re: PgCon: who will be there?

Markus Wanner wrote:
> Well, I think the devil is in the details. Meaning you'll rather get 
> two, three or even more different descriptions (and wishes) than just 
> one. Fleshing out what's usable for most of them (and doesn't hinder 
> the others) is the hard part. And it's not like we did lots of that 
> back in Tokyo.

Sure, which is why I was volunteering to help on this part.  Put me in a 
room full of developers with different opinions and let me listen to the 
argument, and I can usually sort through the whole mess to figure out a 
reasonable summary at the end anyway.

> However, we can start discussing various features of that list right 
> now on this mailing list. That would help a lot in preparation for 
> such an event. I'll start with one that I'm interested in.

That's a pretty good idea; if we could cover some of this background 
before PGCon it would make the whole thing run smoother.

Basically I'd like to see *short* answers to each of the following 
questions for every item listed there:

1) What feature does this help add from a user perspective?
2) Which replication projects would be expected to see an improvement 
from this addition?
3) What makes it difficult to implement?
4) Are there any other items on the list this depends on, or that it is 
expected to have a significant positive/negative interaction with?
5) What replication projects include a feature like this already, or a 
prototype of a similar one, that might be used as a proof of concept or 
example implementation?
6) Who is already working on it/planning to work on it/needs it for 
their related project?

If we picked one item from there a week and brainstormed answers to 
those questions for them all, that could wrap up in time for the 
convention and we'd be starting with an improved basis for discussion 
(as well as input from people like yourself who won't be there).  Much 
like some other PostgreSQL projects (improved table partitioning comes 
to mind), there seems to be lots of code and demos floating around for a 
lot of these clustering/replication, but not enough dependency tracking 
that leads to a clear roadmap for how everything is going to come 
together in the end.

I encourage you to pick a feature you've got interest in and still 
filling in the details for it.  Not like this list is overflowing with 
traffic anyway.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us