Development Plans
I'm giving a talk next week on PostgreSQL 8, so I would like some input
from the community on a few issues, so that my answers are as close to
majority opinion as possible.
One of the most frequent set of questions I get asked is around the
development vision and release strategy of PostgreSQL.
- When is the next release due?
- What will be in release 8.1?
- What are you working towards? Performance? Stability? X?
These are all good questions, you'll note. They mostly indicate that the
person asking the question has already got the more basic messages, and
are preparing themselves to fully accept PostgreSQL as the way forward
*for them*.
I think I've come to understand the answers to many of these questions,
but these answers are not written down. When I do answer them, I try to
make it clear that I present a personal opinion only - but that always
gets strange looks. People really do not understand why there is no
official answer, and take that as a black mark.
Other projects such as Ubuntu, Fedora and OpenOffice have much of this
type of information easily available - certainly commercial software
vendors spend a good deal of time on providing this information.
Could we find a way of expressing the project philosophy in writing, so
I can convey that message out to the world, exactly as intended, without
any Riggs filtering?
My own understandings would be...
- When is the next release due?
I'm happy with the Zen approach of "there is no answer, the code comes
when it is time" and "HACKERS list IS the process".
Many people take the lack of a planned release date as clear indication
that there is no strictly controlled release process, however-much I
state that there really is one. In the absence of release dates, could
we write down some indication of what the release process is, so
everybody understands there is one.
My understanding is:
- new release forked in code repository
- feature freeze, beta phase starts
- string freeze, to allow translations
- release candidate process
- release
Right now, I have zero idea which quarter, let alone which month feature
freeze for 8.1 is in. I think it will be in 2005, but I'm not sure.
[That makes it fairly difficult to get sponsorship for release of new
features, since I cannot guarantee which year they'll be in.]
- what will be in release 8.1?
The TODO list contains a partial mechanism for recording what is being
worked upon by various people. Could that process by beefed up somewhat,
so there is a clear list of Features in Next Release, as part of the
TODO list on the main web site? A caveat could easily warn that this is
a provisional list only and offers no guarantees of inclusion.
I'm happy to make certain commitments to particular features already on
the TODO list. I'm sure others are too.
- What are you working towards? Performance? Stability? X?
When I explain that the pace of development has increased, people
immediately ask which direction things are going in.
In the run-up to r8.0, PITR was listed as an URGENT feature. This gave
some indication of the direction that Core wished the code base to
travel in and gave many a strong indication that they understood the
momentum and trajectory of development.
That section has been removed now.
This is a more difficult one to answer, especially since it really
covers what the major sponsors want.
I'm fairly clear about my own directions: Enterprise features to enhance
robustness, performance and scalability, plus Data Warehousing features
- nearly all of which come from clients or interested parties.
Does anybody else wish to share theirs?
Just so it is clear, there is not a single criticism on this page from
me; I am merely passing on a pattern that I think I see emerging from a
variety of conversations with clients, course attendees and
press/exhibition contacts.
Many thanks,
Best Regards, Simon Riggs
On Fri, 25 Feb 2005, Simon Riggs wrote:
- When is the next release due?
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month dev, 6 month beta) ...
subject to change, but I wouldn't expect a freeze until Jan '06, beta
period might be shorter though ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote:
On Fri, 25 Feb 2005, Simon Riggs wrote:
- When is the next release due?
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month dev, 6 month beta) ...
subject to change, but I wouldn't expect a freeze until Jan '06, beta
period might be shorter though ...
Agreed. That is good target, but might change, as Marc said.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Simon Riggs wrote:
I'm giving a talk next week on PostgreSQL 8, so I would like some input
from the community on a few issues, so that my answers are as close to
majority opinion as possible.One of the most frequent set of questions I get asked is around the
development vision and release strategy of PostgreSQL.- When is the next release due?
- What will be in release 8.1?
- What are you working towards? Performance? Stability? X?These are all good questions, you'll note. They mostly indicate that the
person asking the question has already got the more basic messages, and
are preparing themselves to fully accept PostgreSQL as the way forward
*for them*.I think I've come to understand the answers to many of these questions,
but these answers are not written down. When I do answer them, I try to
make it clear that I present a personal opinion only - but that always
gets strange looks. People really do not understand why there is no
official answer, and take that as a black mark.
Other projects such as Ubuntu, Fedora and OpenOffice have much of this
type of information easily available - certainly commercial software
vendors spend a good deal of time on providing this information.
Could we find a way of expressing the project philosophy in writing, so
I can convey that message out to the world, exactly as intended, without
any Riggs filtering?
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.
How do other open source projects predict these things? The most visible
project I know that did that was Mozilla, and it was very unpredictive,
and they had a higher percentage of paid folks than we do.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Fri, 2005-02-25 at 05:34, Simon Riggs wrote:
I'm giving a talk next week on PostgreSQL 8, so I would like some input
from the community on a few issues, so that my answers are as close to
majority opinion as possible.One of the most frequent set of questions I get asked is around the
development vision and release strategy of PostgreSQL.- When is the next release due?
- What will be in release 8.1?
- What are you working towards? Performance? Stability? X?These are all good questions, you'll note. They mostly indicate that the
person asking the question has already got the more basic messages, and
are preparing themselves to fully accept PostgreSQL as the way forward
*for them*.I think I've come to understand the answers to many of these questions,
but these answers are not written down. When I do answer them, I try to
make it clear that I present a personal opinion only - but that always
gets strange looks. People really do not understand why there is no
official answer, and take that as a black mark.
Other projects such as Ubuntu, Fedora and OpenOffice have much of this
type of information easily available - certainly commercial software
vendors spend a good deal of time on providing this information.
Could we find a way of expressing the project philosophy in writing, so
I can convey that message out to the world, exactly as intended, without
any Riggs filtering?My own understandings would be...
- When is the next release due?
I'm happy with the Zen approach of "there is no answer, the code comes
when it is time" and "HACKERS list IS the process".
Many people take the lack of a planned release date as clear indication
that there is no strictly controlled release process, however-much I
state that there really is one. In the absence of release dates, could
we write down some indication of what the release process is, so
everybody understands there is one.
My understanding is:
- new release forked in code repository
- feature freeze, beta phase starts
- string freeze, to allow translations
- release candidate process
- release
Right now, I have zero idea which quarter, let alone which month feature
freeze for 8.1 is in. I think it will be in 2005, but I'm not sure.
[That makes it fairly difficult to get sponsorship for release of new
features, since I cannot guarantee which year they'll be in.]
As Marc stated, core has decided on a 12 month development cycle, so
that might look like January of next year. If I were speaking to
someone looking to sponsor development, I would tell them they would
need to being work in Q4 of 2005 at the very latest to have a chance of
something going in. As far as when they can expect to see it in a
released branch, Q2 of 2006 would probably be a reasonable estimate.
(I'm hopeful that beta wont take as long this time around since win32
should be more stable and the buildfarm should also be of some help, but
I can't imagine we'd get through it in less than 3 months)
--- update ---Was just about to hit "send" on this email when I saw Tom's post come up
on -hackers talking about a 6 month cycle... so maybe all of the above
is off...
- what will be in release 8.1?
The TODO list contains a partial mechanism for recording what is being
worked upon by various people. Could that process by beefed up somewhat,
so there is a clear list of Features in Next Release, as part of the
TODO list on the main web site? A caveat could easily warn that this is
a provisional list only and offers no guarantees of inclusion.
I'm happy to make certain commitments to particular features already on
the TODO list. I'm sure others are too.
Actually the TODO list is really only a good indicator of things already
in the code... to get an idea of items being discussed you really just
have to hang out on the lists to see what people are working on. A list
of some of what are probably the "big things" being worked on for 8.1
include:
* Improved Resource Managment (this encapsulates the buffer manager
changes and arc replacement and similar work)
* Integrated pg_autovacuum
* Stored procedures (with transaction control and multiple result sets
among other features, not to be confused with function support)
* SQL compatible recursive WITH statements
* 2 Phase Commit
As always none of that stuff is guaranteed but those items have someone
who has stated they want to "make it happen" for 8.1 (and by make it
happen I mean they plan to code it) There are a couple of other big
things floating out there too (bitmapped indexes are a good example),
but I think those are the most concrete. There are also some things that
are cool but probably not big things (OS/2 support for instance)
- What are you working towards? Performance? Stability? X?
When I explain that the pace of development has increased, people
immediately ask which direction things are going in.
In the run-up to r8.0, PITR was listed as an URGENT feature. This gave
some indication of the direction that Core wished the code base to
travel in and gave many a strong indication that they understood the
momentum and trajectory of development.
That section has been removed now.
This is a more difficult one to answer, especially since it really
covers what the major sponsors want.
I would agree that since we have a number of commercial developers who
do have intentions of working on specific items in 8.1, it would be nice
to list those items somewhere (the urgent section of the TODO seems
fine), but it is up to those developers to speak up.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
I would agree that since we have a number of commercial developers who
do have intentions of working on specific items in 8.1, it would be nice
to list those items somewhere (the urgent section of the TODO seems
fine), but it is up to those developers to speak up.
I'd like to bundle pg_dump and pg_dumpall into a single binary, allowing
pg_dumpall in custom (binary) format. Dunno if I'll get the time though :)
I'd also like to backport 8.0's pg_dump to 7.4.x since I think it has
'bug fixes'...
Chris
Bruce Momjian wrote:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.
I agree there is no way to accurately predict such things, however there
was a long list of large features that people were trying to get in for
8.0. So while you can't be sure about what will make it for 8.1, I'm
not even aware of any large projects that anyone is working on. BTW
when I say large project I'm talking about things like the Windows port,
PITR, nested Xacts etc.... Are there any big projects are people
working on to get into 8.1?
On Fri, Feb 25, 2005 at 10:49:59AM -0500, Bruce Momjian wrote:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.How do other open source projects predict these things? The most visible
project I know that did that was Mozilla, and it was very unpredictive,
and they had a higher percentage of paid folks than we do.
Not to sound like a broken FreeBSD drum, but they manage to do it, and
afaik a pretty good job of it.
http://www.freebsd.org/releases/5.4R/todo.html is an example.
http://www.freebsd.org/releases/5.4R/schedule.html is also interesting.
I suspect a big part of why/how they can do this is they have a much
larger developer pool than PostgreSQL; I believe there's over 2000
people with commit access, and there are probably 100-200 people who are
actively developing code for FBSD. But it's been some time since I
followed the details of FBSD development, so I could be way off on these
WAGs.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
"Matthew T. O'Connor" <matthew@zeut.net> writes:
Are there any big projects are people
working on to get into 8.1?
I'm privately hoping to get bitmap index operations into 8.1 (that is,
build a bitmap of tuple locations from an index, possibly AND or OR the
results of multiple indexes, and finally visit the heap in CTID order).
This is not as big as say the Windows port, but it's easily a solid
month or two of effort.
regards, tom lane
Am Freitag, 25. Februar 2005 15:42 schrieb Marc G. Fournier:
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month dev, 6 month beta) ...
subject to change, but I wouldn't expect a freeze until Jan '06, beta
period might be shorter though ...
I certainly hope that this is wrong. I think the past cycles that saw major
releases every 11 or 12 months were OK, albeit too long for my taste, but 18
months is way too long both from the users' and the developers' point of
view.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Am Freitag, 25. Februar 2005 16:49 schrieb Bruce Momjian:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.
A good guess for the features contained in PostgreSQL version X are those that
were first mentioned as targeted for PostgreSQL version X-2. Seriously.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Simon Riggs <simon@2ndquadrant.com> writes:
I'm happy with the Zen approach of "there is no answer, the code comes
when it is time" and "HACKERS list IS the process".
Many people take the lack of a planned release date as clear indication
that there is no strictly controlled release process, however-much I
state that there really is one. In the absence of release dates, could
we write down some indication of what the release process is, so
everybody understands there is one.
What we do not have is a marketing-driven development process ;-).
We let the decisions be dictated by the maturity of the code, not by
an arbitrary predetermined release date. We do try to set a feature
freeze date in advance, but this has always been a pretty sloppy
cutoff --- the reason we set it in advance is just so that individual
developers can make their own plans about how much they think they can
get done in time for the next release. (Awhile back we didn't even do
that, but we found that we were forever slipping a release because first
one feature then another was "almost ready". We have learned that we
must be willing to say "too late for this release".) Once we are past
feature freeze, the beta schedule and release schedule are determined
entirely by Core's judgment about the state of the code.
I think most of the developers consider our process a strength, not
a weakness. It's certainly conditioned by the realities of an open-
source project in which most of the workers are part-time volunteers,
but it works well for us.
Right now, I have zero idea which quarter, let alone which month feature
freeze for 8.1 is in. I think it will be in 2005, but I'm not sure.
I'm sorry about the flux around the 8.1 schedule. It's been caused by
what is hopefully a one-time problem, namely uncertainty about how
we ought to deal with the ARC patent problem. Normally we would have
set a fairly definite feature freeze date before now.
- what will be in release 8.1?
Whatever people get done. In a project where the work is done by
volunteers, it's just about pointless to imagine that we can predict it.
I can say what I'm hoping to work on personally, but how much of it will
get done I don't really know. Multiply that across a few dozen people
and what you have is pretty squishy.
I wouldn't mind seeing people be a little more vocal on the hackers list
about what they plan to be doing, just so that there's not duplication
of effort. But trying to assemble that into some sort of published
Master Plan sounds to me like just a recipe for making ourselves look
foolish when the Plan ends up having little relationship to reality.
- What are you working towards? Performance? Stability? X?
Yes.
Bruce used to try to describe our releases as being oriented towards some
particular goal, but I always thought that these were after-the-fact
descriptions that had nothing to do with the real development process.
The truth is that individual developers work on what they feel like,
or find interesting, or in some cases get paid to do. But just as
there's not a master plan, there's not really some guiding vision that
in a particular release we are going to focus on X or Y or Z.
Note: the above is just my two cents and shouldn't be read as speaking
for Core. I think if you asked the other members of core you'd get
roughly similar answers, but each with his own spin.
regards, tom lane
I wouldn't mind seeing people be a little more vocal on the hackers list
about what they plan to be doing, just so that there's not duplication
of effort. But trying to assemble that into some sort of published
Master Plan sounds to me like just a recipe for making ourselves look
foolish when the Plan ends up having little relationship to reality.
The things I would _like_ to do:
* Combine pg_dump and pg_dumpall into a single binary with common
options, allowing a full cluster custom format dump.
* Make psql backwards compatible like pg_dump is
* Work with a few of the IRC guys on a pgsql version of SQL*Loader.
This would be a rad high speed data loader, with overflow files of rows
that couldn't be loaded, etc.
Chris
On Fri, 25 Feb 2005, Peter Eisentraut wrote:
Am Freitag, 25. Februar 2005 15:42 schrieb Marc G. Fournier:
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month dev, 6 month beta) ...
subject to change, but I wouldn't expect a freeze until Jan '06, beta
period might be shorter though ...I certainly hope that this is wrong. I think the past cycles that saw major
releases every 11 or 12 months were OK, albeit too long for my taste, but 18
months is way too long both from the users' and the developers' point of
view.
Hey, don't shoot the messenger ... I'm just going by what ppl have been
throwing around ... personally, I'd like to a see around an 8-12 month
cycle being the max ... Freeze in Sept, Rel January ... but, of course,
when Sept rolls aroound, there will be someone petitioning for an
extension to get this 'one last feature in', and someone else will rally
up for the cause, and ... 'k, I've gotten a bit jaded over the years? :)
But, 8-12 month seems to be a reasonable amount of time to aim for ... ?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Simon,
Welcome back! Ready to get to work? I need to talk to you about some
stuff ....
- When is the next release due?
Each of our previous 4 releases has taken between 11 and 14 months. So,
early 2006 would not be unlikely; however, we have set no dates yet.
- What will be in release 8.1?
Can't answer that. Let me give you the text I've used with reporters:
"Currently there are developers working on bitmap indexes, database roles,
two-phase commit, faster GiST and R-tree indexes, integrated autovacuum, SQL
standard compliant procedures, and further improvements in memory usage.
However, it is still quite early in the development cycle, and it is very
likely some of these features won't be ready, or won't be good enough, for
8.1, and is equally likely that we will receive and accept four or five other
features that I don't know about yet."
- What are you working towards? Performance? Stability? X?
X, definitely X.
We're working toward PostgreSQL being indisputably the very best SQL RDBMS in
the world.
I think I've come to understand the answers to many of these questions,
but these answers are not written down. When I do answer them, I try to
make it clear that I present a personal opinion only - but that always
gets strange looks. People really do not understand why there is no
official answer, and take that as a black mark.
Well, they're used to dealing with private companies and company-sponsored
projects. These things have marketing-driven agendas. We are a
non-commercial, all-volunteer OSS project. You will need to educate people
on this.
Other projects such as Ubuntu, Fedora and OpenOffice have much of this
type of information easily available
OpenOffice.org and Fedora are both single-company-sponsored projects, with
marketing-driven goals. I don't know about Ubuntu.
- certainly commercial software
vendors spend a good deal of time on providing this information.
Yep. And commercial vendors ship releases whether or not that release is
stable or actually contains the features advertised.
Could we find a way of expressing the project philosophy in writing, so
I can convey that message out to the world, exactly as intended, without
any Riggs filtering?
That's not a small order, if we want to do it right. Why don't you prepare
a Faq-ish page that covers these issues based on the responses you've
received on this thread? I can add it to the Press FAQ.
Right now, I have zero idea which quarter, let alone which month feature
freeze for 8.1 is in. I think it will be in 2005, but I'm not sure.
[That makes it fairly difficult to get sponsorship for release of new
features, since I cannot guarantee which year they'll be in.]
Think early 2006. Tentatively. After all, we haven't discussed feature
freeze date yet.
The TODO list contains a partial mechanism for recording what is being
worked upon by various people. Could that process by beefed up somewhat,
so there is a clear list of Features in Next Release, as part of the
TODO list on the main web site? A caveat could easily warn that this is
a provisional list only and offers no guarantees of inclusion.
I'm happy to make certain commitments to particular features already on
the TODO list. I'm sure others are too.
I've been in favor of converting the TODO list into a pgFoundry-based Task
List, so that TODOs can be claimed by people, for some time.
I'm fairly clear about my own directions: Enterprise features to enhance
robustness, performance and scalability, plus Data Warehousing features
- nearly all of which come from clients or interested parties.
Does anybody else wish to share theirs?
Well, I'll be working on Data Warehousing too.
--
Josh Berkus
Aglio Database Solutions
San Francisco
Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 10:49:59AM -0500, Bruce Momjian wrote:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.How do other open source projects predict these things? The most visible
project I know that did that was Mozilla, and it was very unpredictive,
and they had a higher percentage of paid folks than we do.Not to sound like a broken FreeBSD drum, but they manage to do it, and
afaik a pretty good job of it.
http://www.freebsd.org/releases/5.4R/todo.html is an example.
http://www.freebsd.org/releases/5.4R/schedule.html is also interesting.I suspect a big part of why/how they can do this is they have a much
larger developer pool than PostgreSQL; I believe there's over 2000
people with commit access, and there are probably 100-200 people who are
actively developing code for FBSD. But it's been some time since I
followed the details of FBSD development, so I could be way off on these
WAGs.
Uh, we could do it too if we didn't require each release to be as stable
as the previous one.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Tom Lane wrote:
Bruce used to try to describe our releases as being oriented towards some
particular goal, but I always thought that these were after-the-fact
descriptions that had nothing to do with the real development process.
The truth is that individual developers work on what they feel like,
or find interesting, or in some cases get paid to do. But just as
there's not a master plan, there's not really some guiding vision that
in a particular release we are going to focus on X or Y or Z.
Right, my analysis was always after-the-fact in an attempt to put an
understandable story around the release features, nothing more.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Feb 25, 2005, at 10:36 AM, Tom Lane wrote:
"Matthew T. O'Connor" <matthew@zeut.net> writes:
Are there any big projects are people
working on to get into 8.1?I'm privately hoping to get bitmap index operations into 8.1 (that is,
build a bitmap of tuple locations from an index, possibly AND or OR the
results of multiple indexes, and finally visit the heap in CTID order).
This is not as big as say the Windows port, but it's easily a solid
month or two of effort.
I'd be very excited to see this implemented so I'm happy someone so
high-profile seems to be interested in it getting done. Were you
planning on doing it yourself or are there people you know who are
actively working on it? When you say "hoping" is that "probably, but
no guarantees" or is it more "it'd be nice if someone took the lead on
this"? I'm not offering, I don't think I'd be capable of doing it, but
I'd certainly be interested in following the development and helping
with testing.
--
Jeff Hoffmann
jeff@propertykey.com
Hi Simon;
Here are my observations regarding being a user of the software for the
last five years. Members of the Core should feel free to correct me if
they feel like it.
Simon Riggs wrote:
One of the most frequent set of questions I get asked is around the
development vision and release strategy of PostgreSQL.- When is the next release due?
- What will be in release 8.1?
- What are you working towards? Performance? Stability? X?
Ok, lets get back to development vision and release strategy. In this
case, it doesn't really break down into your three questions.
You have already gotten your answers about release schedule and the
strategy of timing. So lets look at development vision the strategy
regarding what is included in the released version.
The strategy is that it is better to focus on robustness and the correct
way to do things than it is to focus on getting new features in early.
So as Tom (I think) said, this is not a marketing-driven approach.
Instead we have a market-driven approach where features are developed
based on what developers in the market are willing to add either on
their own time or for hire. For this reason it is very difficult to
predict what will be in the release. I know a lot of us were surprised
regarding the inclusion of several (great) features in 8.0 which only
happened because of corporate sponsorship.
The market is not a monolithic entity. It doesn't just focus on one
thing. So I can say with relative certainty that 8.1 will likely have
better performance, be easier to manage, and scale better than our
current version. It will probably also conform more closely to the ANSI
SQL 99 standards and have useful other enterprise features. However
unlike products such as MS SQL Server (or MySQL), our strategy will
likely be guided by what people actually feel the need to fix rather
than what the marketing department things people want to see in the next
version.
I hope that this clarifies the other answers you have received.
Best Wishes
Chris Travers
Jeff Hoffmann <jeff@propertykey.com> writes:
On Feb 25, 2005, at 10:36 AM, Tom Lane wrote:
I'm privately hoping to get bitmap index operations into 8.1 (that is,
build a bitmap of tuple locations from an index, possibly AND or OR the
results of multiple indexes, and finally visit the heap in CTID order).
This is not as big as say the Windows port, but it's easily a solid
month or two of effort.
I'd be very excited to see this implemented so I'm happy someone so
high-profile seems to be interested in it getting done. Were you
planning on doing it yourself or are there people you know who are
actively working on it? When you say "hoping" is that "probably, but
no guarantees" or is it more "it'd be nice if someone took the lead on
this"?
It's more "I want to work on this but can't promise it'll get done".
Once the APIs are sketched out it'd be nice to rope some people into
helping with parts of it.
regards, tom lane
