8.2 planning features

Oleg Bartunov said:

Hi there,

I and Teodor are going to give a talk on conference
"Corporate database systems-2006" here in Moscow and we need info about
new features planned in 8.2 release. Bruce, do you have a list of them
?

Speaking of which, I previously said that I intended to work on providing
first class enumeration types for postgres for 8.2. It's now looking very
unlikely that I'll have time to do that, so if any adventurous soul feels
like doing this or is just looking for a project please speak up - I'm quite
prepared to offer help and suggestions. You'll make thousands of migrating
MySQL users happy.

cheers

andrew

Oleg,

Refer to the Josh's past talk, "PostgreSQL Directions 8.1 and beyond".
MP3 and materials of are available:

http://www.postgresql.jp/misc/seminar/2006-02-17_18/materials/01_Josh_Berkus.pdf
http://www.postgresql.jp/misc/seminar/2006-02-17_18/materials/01_Josh_Berkus.mp3

Thanks,
Satoshi Nagayasu

Oleg Bartunov wrote:

satoshi nagayasu <nagayasus@nttdata.co.jp> writes:

Oleg Bartunov wrote:

I and Teodor are going to give a talk on conference "Corporate database
systems-2006" here in Moscow and we need info about new features planned
in 8.2 release. Bruce, do you have a list of them ?

Refer to the Josh's past talk, "PostgreSQL Directions 8.1 and beyond".
MP3 and materials of are available:

http://www.postgresql.jp/misc/seminar/2006-02-17_18/materials/01_Josh_Berkus.pdf
http://www.postgresql.jp/misc/seminar/2006-02-17_18/materials/01_Josh_Berkus.mp3

BTW, pretty pictures such as Josh draws in the above talk should not be
confused with reality ;-). The reality of this project is that *there
is no overall plan*. Individual developers work on what they choose to.
It's true that at the moment there seem to be quite a number of people
focusing on performance in enterprise-size applications, but that's not
because there's any central plan saying that that's what we're doing.

In particular, asking for a list of features that will be done in
particular future releases shows a complete lack of understanding
of the process ...

regards, tom lane

Tom Lane wrote:

In particular, asking for a list of features that will be done in
particular future releases shows a complete lack of understanding
of the process ...

I completely understand.

However, we also need to know why business people want
to know about the future plan. For the business people,
the roadmap is used to know the software is fit to
their (growing) business, not only now but in the future.

Roadmap can be changed, but still roadmap is necessary
for some kind of users.

Just my opinion...

Thanks,
--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>

On 3/21/06, satoshi nagayasu <nagayasus@nttdata.co.jp> wrote:

However, we also need to know why business people want
to know about the future plan. For the business people,
the roadmap is used to know the software is fit to
their (growing) business, not only now but in the future.

With the current timeline, I'll have hierarchical queries, nonrecursive
introspective sort, and insert/update/delete returning ready for 8.2.

--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324

On Tue, 21 Mar 2006, Tom Lane wrote:

satoshi nagayasu <nagayasus@nttdata.co.jp> writes:

Oleg Bartunov wrote:

I and Teodor are going to give a talk on conference "Corporate database
systems-2006" here in Moscow and we need info about new features planned
in 8.2 release. Bruce, do you have a list of them ?

Refer to the Josh's past talk, "PostgreSQL Directions 8.1 and beyond".
MP3 and materials of are available:

http://www.postgresql.jp/misc/seminar/2006-02-17_18/materials/01_Josh_Berkus.pdf
http://www.postgresql.jp/misc/seminar/2006-02-17_18/materials/01_Josh_Berkus.mp3

BTW, pretty pictures such as Josh draws in the above talk should not be
confused with reality ;-). The reality of this project is that *there
is no overall plan*. Individual developers work on what they choose to.
It's true that at the moment there seem to be quite a number of people
focusing on performance in enterprise-size applications, but that's not
because there's any central plan saying that that's what we're doing.

In particular, asking for a list of features that will be done in
particular future releases shows a complete lack of understanding
of the process ...

I didn't expect such a reaction :) I expected people (developers) know what
they choose (or plan) to work on and just share their thoughts. If there would
be any overall plan I'd not asked -hackers at all. I know, for example, that
we're going to work on inverted index support, which scales full text support.

regards, tom lane

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

On Tuesday 21 March 2006 18:59, satoshi nagayasu wrote:

Tom Lane wrote:

In particular, asking for a list of features that will be done in
particular future releases shows a complete lack of understanding
of the process ...

I completely understand.

However, we also need to know why business people want
to know about the future plan. For the business people,
the roadmap is used to know the software is fit to
their (growing) business, not only now but in the future.

Roadmap can be changed, but still roadmap is necessary
for some kind of users.

I guess we need all talks like this to have a special slide that points out
that if someone doesn't see the feature they need on the list, they can have
it in the next version as long as they're willing to put some resources
behind it. :-)

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert Treat wrote:

On Tuesday 21 March 2006 18:59, satoshi nagayasu wrote:

Tom Lane wrote:

In particular, asking for a list of features that will be done in
particular future releases shows a complete lack of understanding
of the process ...

I completely understand.

However, we also need to know why business people want
to know about the future plan. For the business people,
the roadmap is used to know the software is fit to
their (growing) business, not only now but in the future.

Roadmap can be changed, but still roadmap is necessary
for some kind of users.

I guess we need all talks like this to have a special slide that points out
that if someone doesn't see the feature they need on the list, they can have
it in the next version as long as they're willing to put some resources
behind it. :-)

But it isn't true. Patches get rejected. We won't just automatically
adopt someone's idea if a cool new feature.

My idea of a roadmap would indicate a set of features that had at least
in principle general acceptance and which somebody had undertaken to try
to deliver. Unfortunately, Our TODO list doesn't necessarily meet either
of these criteria. It could also be extended to include some sort of
prioritisation, e.g. "really really want to have", "would like to have",
"would be nice if we can get it in".

The roadmap would be indicative, not prescriptive, i.e. nothing would
stop somebody from delivering a patch for some cool new feature, and
having it considered. And the absence of some feature would not
necessarily inhibit a release. But it would be nice to have some
document that indicated what was likely to be coming down the track
(e.g. I didn't realise that Jonah was going to be doing hierarchical
queries, which will be a very cool thing to have indeed, and one which
many users will drool over.)

cheers

andrew

Tom,

BTW, pretty pictures such as Josh draws in the above talk should not be
confused with reality ;-).

<grin> NOTHING I say should be confused with reality.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Satoshi,

On 3/21/06 3:59 PM, "satoshi nagayasu" <nagayasus@nttdata.co.jp> wrote:

However, we also need to know why business people want
to know about the future plan. For the business people,
the roadmap is used to know the software is fit to
their (growing) business, not only now but in the future.

Roadmap can be changed, but still roadmap is necessary
for some kind of users.

Absolutely.

The Bitmap Index and Sort improvements are features that we have been
developing for the last 10 months based directly on discussions with
business customers. They will be release with Bizgres 0.9 next week, and
contributed to Postgres shortly thereafter (sort already is).

Others on our list of customer driven roadmap items:

- OLAP functions: CUBE, ROLLUP, RANK
- Resource management, incl. dynamic memory management and statement
queueing
- Postgres intrinsic log-shipping replication (we have one to contribute)
- Transparent DML on partitions

Whether these get into 8.2 or not, I'd welcome developer discussion. We are
initiating some planning sessions in mid-April for the next 4-6 months of
development.

- Luke

Its relatively easy for a Business to develop a roadmap, since the
managers delegate their programmers to work on specific features ... in
the case of an OSS project, there are no "assignment of features to work
on" happening ... ppl work on what is of interest to them ... so coming up
with anything more then a 'vapor-roadmap' is impossible ...

On Sat, 25 Mar 2006, Luke Lonergan wrote:

Satoshi,

On 3/21/06 3:59 PM, "satoshi nagayasu" <nagayasus@nttdata.co.jp> wrote:

However, we also need to know why business people want
to know about the future plan. For the business people,
the roadmap is used to know the software is fit to
their (growing) business, not only now but in the future.

Roadmap can be changed, but still roadmap is necessary
for some kind of users.

Absolutely.

The Bitmap Index and Sort improvements are features that we have been
developing for the last 10 months based directly on discussions with
business customers. They will be release with Bizgres 0.9 next week, and
contributed to Postgres shortly thereafter (sort already is).

Others on our list of customer driven roadmap items:

- OLAP functions: CUBE, ROLLUP, RANK
- Resource management, incl. dynamic memory management and statement
queueing
- Postgres intrinsic log-shipping replication (we have one to contribute)
- Transparent DML on partitions

Whether these get into 8.2 or not, I'd welcome developer discussion. We are
initiating some planning sessions in mid-April for the next 4-6 months of
development.

- Luke

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Marc,

Its relatively easy for a Business to develop a roadmap, since the
managers delegate their programmers to work on specific features ... in
the case of an OSS project, there are no "assignment of features to work
on" happening ... ppl work on what is of interest to them ... so coming
up with anything more then a 'vapor-roadmap' is impossible ...

Right. What Luke is saying is that *as a business* GreenPlum is developing
a roadmap for what *they* are going to contribute to PostgreSQL and will
be soliciting input.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

- Postgres intrinsic log-shipping replication (we have one to contribute)

Are you saying you have a working WAL-shipping based portable (means
working well on all platforms) replication already done ? Cause I was
looking into implementing just this one :-)

Do you have some details how it works ?

Cheers,
Csaba.