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(at)2ndQuadrant(dot)com www.2ndQuadrant.us