Two weeks to feature freeze
We have less than two weeks to feature freeze. Win32 is still in an
uncompleted state, and I haven't been able to return to it recently.
Jan is working on getting exec() working, and hopefully someone can help
me on signals. If I get those two done, I think I can tweek Win32 in
minor ways during beta.
I talked to Patrick about PITR, and with JR now back involved, he might
get it done.
Basically, we might get them both in, or it might be a disaster that we
delayed beta for one month.
I am heading to MIT now and will try to get all the outstanding patches
in within the next few days. There are only a few left, mostly ones
that appeared while I was applying the last patch backlog.
I have also been asked to complete my O'Reilly slides by the end of next
week, so I will have little time for Win32.
--
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
We have less than two weeks to feature freeze. Win32 is still in an
uncompleted state, and I haven't been able to return to it recently.
Jan is working on getting exec() working, and hopefully someone can help
me on signals. If I get those two done, I think I can tweek Win32 in
minor ways during beta.I talked to Patrick about PITR, and with JR now back involved, he might
get it done.Basically, we might get them both in, or it might be a disaster that we
delayed beta for one month.
What about the nested transaction stuff?
Do we have any "killer" features added to 7.4 that we can shout about?
There's usually been one or two in the past...?
Chris
On Thu, 2003-06-19 at 01:27, Christopher Kings-Lynne wrote:
We have less than two weeks to feature freeze. Win32 is still in an
uncompleted state, and I haven't been able to return to it recently.
Jan is working on getting exec() working, and hopefully someone can help
me on signals. If I get those two done, I think I can tweek Win32 in
minor ways during beta.I talked to Patrick about PITR, and with JR now back involved, he might
get it done.Basically, we might get them both in, or it might be a disaster that we
delayed beta for one month.What about the nested transaction stuff?
Do we have any "killer" features added to 7.4 that we can shout about?
There's usually been one or two in the past...?
A quick glance at the TODO list shows a number of speed improvements in
specific areas (IN, GROUP BY, Subselects in views), ARRAY improvements,
some utility command improvements / additions, and a significant
protocol update.
The protocol update may not be flashy, but it is a large step forward in
presenting a clean experience for developers using PostgreSQL (reduces
chance of rare, unexpected, and difficult to find logic errors).
If nothing else, it makes for an excellent cleanup release that rounds
off some of the sharp corners (tab completion for schema elements in
psql, schema dump in psql, fixed cluster support, transactional
truncate, alter sequence, new regex code for fast MultiByte, etc).
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
On Wed, 2003-06-18 at 21:27, Christopher Kings-Lynne wrote:
Do we have any "killer" features added to 7.4 that we can shout about?
There's usually been one or two in the past...?
Isn't the index growth problem solved in this release? I think that is
a killer feature that solves a big problem for alot of people.
On Wed, Jun 18, 2003 at 09:59:17PM -0400, Matthew T. O'Connor wrote:
On Wed, 2003-06-18 at 21:27, Christopher Kings-Lynne wrote:
Do we have any "killer" features added to 7.4 that we can shout about?
There's usually been one or two in the past...?Isn't the index growth problem solved in this release? I think that is
a killer feature that solves a big problem for alot of people.
Yes. That qualifies for "killer features" at least to some big users
here.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Granting software the freedom to evolve guarantees only different results,
not better ones." (Zygo Blaxell)
On Thu, Jun 19, 2003 at 09:27:22AM +0800, Christopher Kings-Lynne wrote:
We have less than two weeks to feature freeze.
What about the nested transaction stuff?
I don't know if it will be completed before feature freeze... we can and
will try, of course. Sadly, like most other people, I have lots of
other things and can't give it the time I wish.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... �Qui�n es el machito que tendr�a carnet?" (Mafalda)
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
What about the nested transaction stuff?
With all due respect to Alvaro et al, I can't imagine that that will
make it into 7.4. (I have no confidence that PITR or Win32 native port
will make it either...)
Do we have any "killer" features added to 7.4 that we can shout about?
We have a lot of pretty good stuff. You're not happy that the
performance of IN (subselect) has been fixed? That btree index bloat is
fixed (at least in large part, it remains to be seen whether the field
performance is all that we need...)?
In my opinion the project is not at a state where whizzy new Features
with a capital F are going to jump out of the woodwork. We are making
good advances in performance, reliability, SQL spec compliance, and
stuff like that, but fancy-sounding bullet points are hard to come by.
I can tell you that Red Hat's CCM group (the former Ars Digita) is
waiting with bated breath for 7.4, because it fixes a number of problems
(IN-subselect being one) that prevent 7.3 from being a serious
competitor to Oracle for their platform. 7.4 is a killer release for
them, and has been since about February, and they're getting tired of
waiting. I think a lot of other people are in the same situation,
even though they may not know it ;-)
We can't slip this puppy any more --- it's time to wrap her up and
push her out.
regards, tom lane
On Thu, 19 Jun 2003, Christopher Kings-Lynne wrote:
We have less than two weeks to feature freeze. Win32 is still in an
uncompleted state, and I haven't been able to return to it recently.
Jan is working on getting exec() working, and hopefully someone can help
me on signals. If I get those two done, I think I can tweek Win32 in
minor ways during beta.I talked to Patrick about PITR, and with JR now back involved, he might
get it done.Basically, we might get them both in, or it might be a disaster that we
delayed beta for one month.What about the nested transaction stuff?
Do we have any "killer" features added to 7.4 that we can shout about?
There's usually been one or two in the past...?
I'm not sure if contrib/tsearch is a "killer" feature, but we hope
to submit completely new version of tsearch V2 before July 1.
Actually, we have stable code already used in some projects but
currently lacking documentation. Several people are working on tutorial,
reference guide. The problem is that Bruce seems is very overloaded and
for sure he'll have many patches close to July 1. Is it possible
to get rights to commit our changes ?
Chris
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
Maybe a better strategy would be to get a release out soon but not wait 6
months for another release which would contain the Win32 port and the PITR
stuff (assuming those aren't done in time for this release).
Just a thought.
andrew
Tom Lane wrote:
Show quoted text
Robert Treat <xzilla@users.sourceforge.net> writes:
Well, I suppose that history has shown that waiting on specific
features causes trouble with postgresql development, but I don't see
why a release can't be based around waiting for feature x as long as
feature x is being actively worked on by trusted developers who have
an endgame in sight.We have been led down that garden path before, and it's been a losing
proposition every time.
Import Notes
Reply to msg id not found: 8111.1056029929@sss.pgh.pa.usReference msg id not found: 8111.1056029929@sss.pgh.pa.us | Resolved by subject fallback
On Thursday 19 June 2003 03:27, Christopher Kings-Lynne wrote:
Do we have any "killer" features added to 7.4 that we can shout about?
We should not forget the availability of PostgreSQL companion products, like
pgAdmin3 and PhpPgAdmin3. These two GUIs should be ready for release during
July, although I am not in the shoes of the project leaders, Dave and
Christopher and cannot speak of it officially.
They are not part of the PostgreSQL distribution, but well could be.
Providing a reliable bundle including PostgreSQL, a graphical GUI (pgAdmin3)
and a web administration interface (PhpPgAdmin3) is a big news. This will
convince entry users, who normally turn to MySQL, that PostgreSQL is the best
choice. We are not downgrading features but upgrading user needs...
When PostgreSQL win32 port is ready, all platforms and entry user needs will
be covered. Isn't it a big news? Just my 2 cents...
Best regards,
Jean-Michel POURE
On Wed, 2003-06-18 at 23:07, Tom Lane wrote:
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
What about the nested transaction stuff?
With all due respect to Alvaro et al, I can't imagine that that will
make it into 7.4. (I have no confidence that PITR or Win32 native port
will make it either...)
Heres hoping for win32, that is a killer feature for so many people and
we're so close to it...
Do we have any "killer" features added to 7.4 that we can shout about?
We have a lot of pretty good stuff. You're not happy that the
performance of IN (subselect) has been fixed? That btree index bloat is
fixed (at least in large part, it remains to be seen whether the field
performance is all that we need...)?
I think the auto vacuum work will be pretty big, and I personally think
statement level triggers are pretty important too. (Which reminds me I
really need to start banging on those a bit more.)
In my opinion the project is not at a state where whizzy new Features
with a capital F are going to jump out of the woodwork. We are making
good advances in performance, reliability, SQL spec compliance, and
stuff like that, but fancy-sounding bullet points are hard to come by.
You mean like that other database that just recently added transaction
support ;-)
I do see a number of capital F features that haven't been done yet,
win32, replication, nested transactions... imho those features could
each warrant a development cycle on their own.
I can tell you that Red Hat's CCM group (the former Ars Digita) is
waiting with bated breath for 7.4, because it fixes a number of problems
(IN-subselect being one) that prevent 7.3 from being a serious
competitor to Oracle for their platform. 7.4 is a killer release for
them, and has been since about February, and they're getting tired of
waiting. I think a lot of other people are in the same situation,
even though they may not know it ;-)We can't slip this puppy any more --- it's time to wrap her up and
push her out.
Well, I suppose that history has shown that waiting on specific features
causes trouble with postgresql development, but I don't see why a
release can't be based around waiting for feature x as long as feature x
is being actively worked on by trusted developers who have an endgame in
sight.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat <xzilla@users.sourceforge.net> writes:
Well, I suppose that history has shown that waiting on specific features
causes trouble with postgresql development, but I don't see why a
release can't be based around waiting for feature x as long as feature x
is being actively worked on by trusted developers who have an endgame in
sight.
We have been led down that garden path before, and it's been a losing
proposition every time.
regards, tom lane
On Thu, 2003-06-19 at 06:12, Andrew Dunstan wrote:
Maybe a better strategy would be to get a release out soon but not wait 6
months for another release which would contain the Win32 port and the PITR
stuff (assuming those aren't done in time for this release).
Thats what Justin was saying about this one, that it should be released
early due to win32 being complete.
I would expect, even once it compiles and runs (it doesn't yet) that it
will need some good testing before being released in any form. Platform
changes of this significance tend to introduce lots of new and
unexpected issues.
Tracking down several users for windows testing is a good idea. Rushing
it out in an unknown state to get the testing isn't such a good idea in
my mind.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
Tom wrote:
Do we have any "killer" features added to 7.4 that we can shout about?
We have a lot of pretty good stuff. You're not happy that the
performance of IN (subselect) has been fixed? That btree index bloat is
fixed...
For warehousing & reporting, "Add hash for evaluating GROUP BY aggregates"
can be a killer feature.
7.4 is a killer release for them, and has been since about February,
and they're getting tired of waiting. I think a lot of other people
are in the same situation, even though they may not know it ;-)
A nightly reporting process that starts here at midnight each night
takes about 12 hours on 7.3 and about 9 hours on 7.4alpha; possibly
thanks to HashAggregates. While this may not sound like much, it
means Marketing could see results when they arive at work, instead
of waiting for afternoon.
The perceived improvement of "ready before work" vs. "wait three hours"
is a killer feature for this system.
Ron
On Thu, 19 Jun 2003, Robert Treat wrote:
Well, I suppose that history has shown that waiting on specific features
causes trouble with postgresql development, but I don't see why a
release can't be based around waiting for feature x as long as feature x
is being actively worked on by trusted developers who have an endgame in
sight.
Everyone has an 'endgame in sight', at least when they ask for a release
to be postponed ... but then their date keeps slipping, etc ...
The thing is, if win32 is 'that close to being finished', then as soon as
v7.4 is out, that code should be ready to throw in ... and the same for
every other features that could 'postpone a release' ...
I'd rather see the dev cycle shortened by a month, then extended ...
We have a lot of pretty good stuff. You're not happy that the
performance of IN (subselect) has been fixed?
All our code uses workaround now :)
That btree index bloat is
fixed (at least in large part, it remains to be seen whether the field
performance is all that we need...)?
Yes, that's a good feature.
We can't slip this puppy any more --- it's time to wrap her up and
push her out.
OK, let's do it - we've got full support for it in phpPgAdmin already :)
Chris
On Thu, 19 Jun 2003, Andrew Dunstan wrote:
Maybe a better strategy would be to get a release out soon but not wait
6 months for another release which would contain the Win32 port and the
PITR stuff (assuming those aren't done in time for this release).Just a thought.
And definitely in agreement here ... I'd rather see a shortened dev cycle
prompted by a big feature being added, then delaying a release because "oh
oh, I need another few weeks" that draws out when something unexpected
happens :(
andrew
Tom Lane wrote:
Robert Treat <xzilla@users.sourceforge.net> writes:
Well, I suppose that history has shown that waiting on specific
features causes trouble with postgresql development, but I don't see
why a release can't be based around waiting for feature x as long as
feature x is being actively worked on by trusted developers who have
an endgame in sight.We have been led down that garden path before, and it's been a losing
proposition every time.---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Thu, 19 Jun 2003, Oleg Bartunov wrote:
I'm not sure if contrib/tsearch is a "killer" feature, but we hope to
submit completely new version of tsearch V2 before July 1. Actually, we
have stable code already used in some projects but currently lacking
documentation. Several people are working on tutorial, reference guide.
The problem is that Bruce seems is very overloaded and for sure he'll
have many patches close to July 1. Is it possible to get rights to
commit our changes ?
Is there a strong reason why tsearch isn't in gborg?
On Thu, 19 Jun 2003, The Hermit Hacker wrote:
On Thu, 19 Jun 2003, Oleg Bartunov wrote:
I'm not sure if contrib/tsearch is a "killer" feature, but we hope to
submit completely new version of tsearch V2 before July 1. Actually, we
have stable code already used in some projects but currently lacking
documentation. Several people are working on tutorial, reference guide.
The problem is that Bruce seems is very overloaded and for sure he'll
have many patches close to July 1. Is it possible to get rights to
commit our changes ?Is there a strong reason why tsearch isn't in gborg?
How gborg could help us submitting changes to pgsql CVS ?
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
On Fri, 20 Jun 2003, Oleg Bartunov wrote:
Is there a strong reason why tsearch isn't in gborg?
How gborg could help us submitting changes to pgsql CVS ?
It wouldn't ... is there a reason why tsearch needs to be in the pgsql CVS
any more then, say, ODBC drivers, or the tcl interface, or the python
interface, or ... ?
