State of Beta 2

[Joshua D. Drake]

Re: State of Beta 2

[color=blue]
>
> And that has nothing to do with user need as a whole, since the care
> level I mentioned is predicated by the developer interest level.
> While I know, Marc, how the whole project got started (I have read the
> first posts), and I appreciate that you, Bruce, Thomas, and Vadim
> started the original core team because you were and are users of
> PostgreSQL, I sincerely believe that in this instance you are out of
> touch with this need of many of today's userbase. And I say that with
> full knowledge of PostgreSQL Inc.'s support role. If given the choice
> between upgrading capability, PITR, and Win32 support, my vote would
> go to upgrading. Then migrating to PITR won't be a PITN.[/color]

If someone is willing to pony up 2000.00 per month for a period of at
least 6 months, I will dedicated one of my programmers to the task. So
if you want it bad enough there it is. I will donate all changes,
patches etc.. to the project and I will cover the additional costs that
are over and above the 12,000. If we get it done quicker, all the better.

Sincerely,

Joshua Drake

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandpromp t.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Network Administrator]

Re: State of Beta 2

Hmmm, ok, I can't retask any of my people or reallocation funds for this year
but I can personally do 5 to 10% of that monthly cost.

Some more people and project plan- then the ball could roll :)

Quoting "Joshua D. Drake" <jd@commandprom pt.com>:
[color=blue]
>[color=green]
> >
> > And that has nothing to do with user need as a whole, since the care
> > level I mentioned is predicated by the developer interest level.
> > While I know, Marc, how the whole project got started (I have read the
> > first posts), and I appreciate that you, Bruce, Thomas, and Vadim
> > started the original core team because you were and are users of
> > PostgreSQL, I sincerely believe that in this instance you are out of
> > touch with this need of many of today's userbase. And I say that with
> > full knowledge of PostgreSQL Inc.'s support role. If given the choice
> > between upgrading capability, PITR, and Win32 support, my vote would
> > go to upgrading. Then migrating to PITR won't be a PITN.[/color]
>
> If someone is willing to pony up 2000.00 per month for a period of at
> least 6 months, I will dedicated one of my programmers to the task. So
> if you want it bad enough there it is. I will donate all changes,
> patches etc.. to the project and I will cover the additional costs that
> are over and above the 12,000. If we get it done quicker, all the better.
>
> Sincerely,
>
> Joshua Drake
>
> --
> Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
> Postgresql support, programming shared hosting and dedicated hosting.
> +1-503-222-2783 - jd@commandpromp t.com - http://www.commandprompt.com
> The most reliable support for the most reliable Open Source database.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>[/color]


--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.

http://vcsn.com

_______________ _______________ ______
This email account is being host by:
VCSN, Inc : http://vcsn.com

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Andrew Rawnsley]

Re: State of Beta 2


Let me run some numbers. I'm interested in the idea, and I think I can
push one of my clients on it.

Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that
sort of time commitment? Is it maintainable over time? Or are we
pissing in the wind?

On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote:
[color=blue]
>[color=green]
>>
>> And that has nothing to do with user need as a whole, since the care
>> level I mentioned is predicated by the developer interest level.
>> While I know, Marc, how the whole project got started (I have read
>> the first posts), and I appreciate that you, Bruce, Thomas, and Vadim
>> started the original core team because you were and are users of
>> PostgreSQL, I sincerely believe that in this instance you are out of
>> touch with this need of many of today's userbase. And I say that with
>> full knowledge of PostgreSQL Inc.'s support role. If given the
>> choice between upgrading capability, PITR, and Win32 support, my vote
>> would go to upgrading. Then migrating to PITR won't be a PITN.[/color]
>
> If someone is willing to pony up 2000.00 per month for a period of at
> least 6 months, I will dedicated one of my programmers to the task. So
> if you want it bad enough there it is. I will donate all changes,
> patches etc.. to the project and I will cover the additional costs
> that are over and above the 12,000. If we get it done quicker, all the
> better.
>
> Sincerely,
>
> Joshua Drake
>
> --
> Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
> Postgresql support, programming shared hosting and dedicated hosting.
> +1-503-222-2783 - jd@commandpromp t.com - http://www.commandprompt.com
> The most reliable support for the most reliable Open Source database.
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 8: explain analyze is your friend
>[/color]
--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114

https://www.ravensfield.com

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Marc G. Fournier]

Re: State of Beta 2


[color=blue][color=green]
> > And that has nothing to do with user need as a whole, since the care
> > level I mentioned is predicated by the developer interest level.
> > While I know, Marc, how the whole project got started (I have read the
> > first posts), and I appreciate that you, Bruce, Thomas, and Vadim
> > started the original core team because you were and are users of
> > PostgreSQL, I sincerely believe that in this instance you are out of
> > touch with this need of many of today's userbase.[/color][/color]

Huh? I have no disagreement that upgrading is a key feature that we are
lacking ... but, if there are any *on disk* changes between releases, how
do you propose 'in place upgrades'? Granted, if its just changes to the
system catalogs and such, pg_upgrade should be able to be taught to handle
it .. I haven't seen anyone step up to do so, and for someone spending so
much time pushing for an upgrade path, I haven't seen you pony up the time
....

Just curious here ... but, with all the time you've spent pushing for an
"easy upgrade path", have you looked at the other RDBMSs and how they deal
with upgrades? I think its going to be a sort of apples-to-oranges thing,
since I imagine that most of the 'big ones' don't change their disk
formats anymore ...

What I'd be curious about is how badly we compare as far as major releases
are concerned ... I don't believe we've had a x.y.z release yet that
required a dump/reload (and if so, it was a very very special
circumstance), but what about x.y releases? In Oracle's case, i don't
think they do x.y.z releases, do they? Only X and x.y?

K, looking back through that it almost sounds like a ramble ... hopefully
you understand what I'm asking ...

I know when I was at the University, and they dealt with Oracle upgrades,
the guys plan'd for a weekend ...

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Mike Mascari]

Re: State of Beta 2

Lamar Owen wrote:
[color=blue]
> And that has nothing to do with user need as a whole, since the care
> level I mentioned is predicated by the developer interest level. While
> I know, Marc, how the whole project got started (I have read the first
> posts), and I appreciate that you, Bruce, Thomas, and Vadim started the
> original core team because you were and are users of PostgreSQL, I
> sincerely believe that in this instance you are out of touch with this
> need of many of today's userbase. And I say that with full knowledge of
> PostgreSQL Inc.'s support role. If given the choice between upgrading
> capability, PITR, and Win32 support, my vote would go to upgrading. Then
> migrating to PITR won't be a PITN.[/color]

Ouch. I'd like to see an easy upgrade path, but I'd rather have a 7.5
with PITR then an in-place upgrade. Perhaps the demand for either is
associated with the size of the db vs. the fear associated with an
inability to restore to a point-in-time. My fear of an accidental:

DELETE FROM foo;

is greater than my loathing of the upgrade process.
[color=blue]
> What good are great features if it's a PITN to get upgraded to them?[/color]

What good is an in-place upgrade without new features?

(I'm kinda joking here) ;-)

Mike Mascari
mascarm@mascari .com




---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Dennis Gearon]

Re: State of Beta 2

It's be EXTREMELY cool if there was some relationship betweenn the code for;

PITR and
Inplace upgrades

Any possibility of overlaps?

Mike Mascari wrote:
[color=blue]
>Lamar Owen wrote:
>
>
>[color=green]
>>And that has nothing to do with user need as a whole, since the care
>>level I mentioned is predicated by the developer interest level. While
>>I know, Marc, how the whole project got started (I have read the first
>>posts), and I appreciate that you, Bruce, Thomas, and Vadim started the
>>original core team because you were and are users of PostgreSQL, I
>>sincerely believe that in this instance you are out of touch with this
>>need of many of today's userbase. And I say that with full knowledge of
>>PostgreSQL Inc.'s support role. If given the choice between upgrading
>>capability, PITR, and Win32 support, my vote would go to upgrading. Then
>>migrating to PITR won't be a PITN.
>>
>>[/color]
>
>Ouch. I'd like to see an easy upgrade path, but I'd rather have a 7.5
>with PITR then an in-place upgrade. Perhaps the demand for either is
>associated with the size of the db vs. the fear associated with an
>inability to restore to a point-in-time. My fear of an accidental:
>
>DELETE FROM foo;
>
>is greater than my loathing of the upgrade process.
>
>
>[color=green]
>>What good are great features if it's a PITN to get upgraded to them?
>>
>>[/color]
>
>What good is an in-place upgrade without new features?
>
>(I'm kinda joking here) ;-)
>
>Mike Mascari
>mascarm@mascar i.com
>
>
>
>
>
>[/color]


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[scott.marlowe]

Re: State of Beta 2

As I understand it, changes that require the dump restore fall into two
categories, catalog changes, and on disk format changes. If that's the
case (I'm as likely wrong as right here, I know) then it could be that
most upgrades (say 7.4 to 7.5) could be accomplished more easier than the
occasional ones that require actual disk format changes (i.e. 7.5 to 8.0)

If that's the case, I'd imagine that as postgresql gets more mature, on
disk upgrades should become easier to implement, and dump/restore would
only be required for major version upgrades at some point.

Is that about right, and if so, would it make maintaining this kind of
program simpler if it only had to handle catalog changes?

On Tue, 16 Sep 2003, Andrew Rawnsley wrote:
[color=blue]
>
> Let me run some numbers. I'm interested in the idea, and I think I can
> push one of my clients on it.
>
> Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that
> sort of time commitment? Is it maintainable over time? Or are we
> pissing in the wind?
>
> On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote:
>[color=green]
> >[color=darkred]
> >>
> >> And that has nothing to do with user need as a whole, since the care
> >> level I mentioned is predicated by the developer interest level.
> >> While I know, Marc, how the whole project got started (I have read
> >> the first posts), and I appreciate that you, Bruce, Thomas, and Vadim
> >> started the original core team because you were and are users of
> >> PostgreSQL, I sincerely believe that in this instance you are out of
> >> touch with this need of many of today's userbase. And I say that with
> >> full knowledge of PostgreSQL Inc.'s support role. If given the
> >> choice between upgrading capability, PITR, and Win32 support, my vote
> >> would go to upgrading. Then migrating to PITR won't be a PITN.[/color]
> >
> > If someone is willing to pony up 2000.00 per month for a period of at
> > least 6 months, I will dedicated one of my programmers to the task. So
> > if you want it bad enough there it is. I will donate all changes,
> > patches etc.. to the project and I will cover the additional costs
> > that are over and above the 12,000. If we get it done quicker, all the
> > better.
> >
> > Sincerely,
> >
> > Joshua Drake
> >
> > --
> > Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
> > Postgresql support, programming shared hosting and dedicated hosting.
> > +1-503-222-2783 - jd@commandpromp t.com - http://www.commandprompt.com
> > The most reliable support for the most reliable Open Source database.
> >
> >
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 8: explain analyze is your friend
> >[/color]
> --------------------
>
> Andrew Rawnsley
> President
> The Ravensfield Digital Resource Group, Ltd.
> (740) 587-0114
> www.ravensfield.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)
>[/color]


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Andrew Rawnsley]

Re: State of Beta 2


On Tuesday, September 16, 2003, at 04:51 PM, Marc G. Fournier wrote:[color=blue]
>
> Just curious here ... but, with all the time you've spent pushing for
> an
> "easy upgrade path", have you looked at the other RDBMSs and how they
> deal
> with upgrades? I think its going to be a sort of apples-to-oranges
> thing,
> since I imagine that most of the 'big ones' don't change their disk
> formats anymore ...
>[/color]

That's probably the thing - they've written the on-disk stuff in stone
by now. DB2 has
a lot of function rebinding to do, but thats probably a different issue.

Tying to my last post, concerning Joshua's offer to put up the labor if
we can put up the dough, given the
fact that Postgres is still in flux, do you think its even possible to
do some sort of in-place upgrade, not knowing
what may come up when you're writing 7.6?

In other words, if we pony up and get something written now, will it
need further development every time an x.y release comes up.
[color=blue]
> What I'd be curious about is how badly we compare as far as major
> releases
> are concerned ... I don't believe we've had a x.y.z release yet that
> required a dump/reload (and if so, it was a very very special
> circumstance), but what about x.y releases? In Oracle's case, i don't
> think they do x.y.z releases, do they? Only X and x.y?
>[/color]

Lord, who knows what they're up to. They do (or did) x.y.z releases
(I'm using 8.1.6), but publicly they're
calling everything 8i,9i,10g yahdah yahdah yahdah.

I certainly will concede that (to me), upgrading Postgres is easier
than Oracle, as I can configure, compile, install,
do an initdb, and generate an entire large DDL in the time it takes the
abysmal Oracle installer to even start. Then try
to install/upgrade it on an 'unsupported' linux, like Slack...but I
don't have to do anything with the data.

To a PHB/PHC (pointy-haired-client), saying 'Oracle' is like giving
them a box of Depends, even though it doesn't save them
from a fire hose. They feel safe.
[color=blue]
> K, looking back through that it almost sounds like a ramble ...
> hopefully
> you understand what I'm asking ...
>
> I know when I was at the University, and they dealt with Oracle
> upgrades,
> the guys plan'd for a weekend ...
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>[/color]
--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114

https://www.ravensfield.com

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Joshua D. Drake]

Re: State of Beta 2

Hello,

I would imagine that it would be maintainable but it would be
something that would have to be
constantly maintained from release to release. It would have to become
part of the actual project or
it would die.

The reason I chose six months is that I figure it will be 30 days of
full time just dinking around to make
sure that we have a solid handle on how things are done for this part of
the code. Then we would know
what we think it would take. It was a gut theory but I believe it can be
done or at least a huge jump on it.


Sincerely,

Joshua Drake


Andrew Rawnsley wrote:
[color=blue]
>
> Let me run some numbers. I'm interested in the idea, and I think I can
> push one of my clients on it.
>
> Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that
> sort of time commitment? Is it maintainable over time? Or are we
> pissing in the wind?
>
> On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote:
>[color=green]
>>[color=darkred]
>>>
>>> And that has nothing to do with user need as a whole, since the care
>>> level I mentioned is predicated by the developer interest level.
>>> While I know, Marc, how the whole project got started (I have read
>>> the first posts), and I appreciate that you, Bruce, Thomas, and
>>> Vadim started the original core team because you were and are users
>>> of PostgreSQL, I sincerely believe that in this instance you are out
>>> of touch with this need of many of today's userbase. And I say that
>>> with full knowledge of PostgreSQL Inc.'s support role. If given the
>>> choice between upgrading capability, PITR, and Win32 support, my
>>> vote would go to upgrading. Then migrating to PITR won't be a PITN.[/color]
>>
>>
>> If someone is willing to pony up 2000.00 per month for a period of at
>> least 6 months, I will dedicated one of my programmers to the task.
>> So if you want it bad enough there it is. I will donate all changes,
>> patches etc.. to the project and I will cover the additional costs
>> that are over and above the 12,000. If we get it done quicker, all
>> the better.
>>
>> Sincerely,
>>
>> Joshua Drake
>>
>> --
>> Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
>> Postgresql support, programming shared hosting and dedicated hosting.
>> +1-503-222-2783 - jd@commandpromp t.com - http://www.commandprompt.com
>> The most reliable support for the most reliable Open Source database.
>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 8: explain analyze is your friend
>>[/color]
> --------------------
>
> Andrew Rawnsley
> President
> The Ravensfield Digital Resource Group, Ltd.
> (740) 587-0114
> www.ravensfield.com[/color]


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandpromp t.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Joshua D. Drake]

Re: State of Beta 2

[color=blue]
> Tying to my last post, concerning Joshua's offer to put up the labor
> if we can put up the dough, given the
> fact that Postgres is still in flux, do you think its even possible to
> do some sort of in-place upgrade, not knowing
> what may come up when you're writing 7.6?
>
> In other words, if we pony up and get something written now, will it
> need further development every time an x.y release comes up.[/color]

There is probably no question that it will need further development.
However, I would imagine that once the intial grunt work is done it
would be much easier to migrate the code (especially if it is
continually maintained) to newer releases.

My thought process is that we would start with 7.4 codebase and as it
migrates to 7.5 move the work directly to 7.5 and if possible release
for 7.5 (although that really may be pushing it).

J



[color=blue]
>[color=green]
>> What I'd be curious about is how badly we compare as far as major
>> releases
>> are concerned ... I don't believe we've had a x.y.z release yet that
>> required a dump/reload (and if so, it was a very very special
>> circumstance), but what about x.y releases? In Oracle's case, i don't
>> think they do x.y.z releases, do they? Only X and x.y?
>>[/color]
>
> Lord, who knows what they're up to. They do (or did) x.y.z releases
> (I'm using 8.1.6), but publicly they're
> calling everything 8i,9i,10g yahdah yahdah yahdah.
>
> I certainly will concede that (to me), upgrading Postgres is easier
> than Oracle, as I can configure, compile, install,
> do an initdb, and generate an entire large DDL in the time it takes
> the abysmal Oracle installer to even start. Then try
> to install/upgrade it on an 'unsupported' linux, like Slack...but I
> don't have to do anything with the data.
>
> To a PHB/PHC (pointy-haired-client), saying 'Oracle' is like giving
> them a box of Depends, even though it doesn't save them
> from a fire hose. They feel safe.
>[color=green]
>> K, looking back through that it almost sounds like a ramble ...
>> hopefully
>> you understand what I'm asking ...
>>
>> I know when I was at the University, and they dealt with Oracle
>> upgrades,
>> the guys plan'd for a weekend ...
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 4: Don't 'kill -9' the postmaster
>>[/color]
> --------------------
>
> Andrew Rawnsley
> President
> The Ravensfield Digital Resource Group, Ltd.
> (740) 587-0114
> www.ravensfield.com[/color]


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandpromp t.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Robert Creager]

Re: State of Beta 2

Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
"Joshua D. Drake" <jd@commandprom pt.com> uttered something amazingly similar to:
[color=blue]
> If someone is willing to pony up 2000.00 per month for a period of at
> least 6 months, I will dedicated one of my programmers to the task. So
> if you want it bad enough there it is. I will donate all changes,
> patches etc.. to the project and I will cover the additional costs that
> are over and above the 12,000. If we get it done quicker, all the better.
>[/color]

Well, if you're willing to set up some sort of escrow, I'll put in $100. I
don't do db's except for play, but I hate the dump/restore part. I've lost data
two times fat-fingering the upgrade, trying to use two running installations on
the same machine. I'm that good...

Cheers,
Rob

--
21:28:34 up 46 days, 14:03, 4 users, load average: 2.00, 2.00, 2.00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iEYEARECAAYFAj9 n1mcACgkQgy51bQ c2FFkTZgCgmYhKA D7BTMx/HLrBpHgqvDWe
wiEAoMGcWzsR4O+ DBBLjxUC36eaNrh Ut
=b9c5
-----END PGP SIGNATURE-----

[Dennis Gearon]

Re: State of Beta 2

Robert Creager wrote:
[color=blue]
>Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
>"Joshua D. Drake" <jd@commandprom pt.com> uttered something amazingly similar to:
>
>
>[color=green]
>>If someone is willing to pony up 2000.00 per month for a period of at
>>least 6 months, I will dedicated one of my programmers to the task. So
>>if you want it bad enough there it is. I will donate all changes,
>>patches etc.. to the project and I will cover the additional costs that
>>are over and above the 12,000. If we get it done quicker, all the better.
>>
>>
>>[/color]
>
>Well, if you're willing to set up some sort of escrow, I'll put in $100. I
>don't do db's except for play, but I hate the dump/restore part. I've lost data
>two times fat-fingering the upgrade, trying to use two running installations on
>the same machine. I'm that good...
>
>Cheers,
>Rob
>
>
>[/color]
Is that $100 times once, or $100 X 6mos anticiapated develop time.


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Re: State of Beta 2

Andrew Rawnsley <ronz@ravensfie ld.com> writes:[color=blue]
> On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote:[color=green]
>> If someone is willing to pony up 2000.00 per month for a period of at
>> least 6 months, I will dedicated one of my programmers to the task.[/color][/color]
[color=blue]
> Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that
> sort of time commitment?[/color]

While I dislike staring gift horses in the mouth, I have to say that
the people I think could do it (a) are getting paid more than $24K/yr,
and (b) are names already seen regularly in the PG commit logs. If
there's anyone in category (b) who works for Command Prompt, I missed
the connection.

I have no doubt that a competent programmer could learn the Postgres
innards well enough to do the job; as someone pointed out earlier in
this thread, none of the core committee was born knowing Postgres.
I do, however, doubt that it can be done in six months if one has
any significant learning curve to climb up first.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Kaare Rasmussen]

Re: State of Beta 2

>> If someone is willing to pony up 2000.00 per month for a period of at[color=blue][color=green]
>> least 6 months, I will dedicated one of my programmers to the task.[/color][/color]

I stated the "how much will it cost" question, but I'm beginning to think that
it's the wrong approach. From the answers in this thread I do believe that it
will be an eternal chase with almost certainty of errors.

Some people have claimed that the big commercial databases don't change their
on-disk represantation anymore. Maybe PostgreSQL could try to aim for this
goal. At least try to get the on-disk changes ready for 7.5 - with or without
the functionality to use it. I think that any pg_* table changes could be
done with a small and efficient pg_upgrade.

Big items that will change the way PostgreSQL stores its data would be
Tablespaces
PITR
....
More ?

I know it's not possible to tell the future, but if Oracle is steady,
shouldn't it be possible?

How do other Open Source systems do ? MySQL (or maybe better: InnoDB),
FireBird ??

--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Email: kar@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Peter Childs]

Re: State of Beta 2

On Wed, 17 Sep 2003, Kaare Rasmussen wrote:
[color=blue]
>
> How do other Open Source systems do ? MySQL (or maybe better: InnoDB),
> FireBird ??
>
>[/color]
Well MySql for one has more than one on-disk format....
One that supports transactions and one that does not. Looks like they do
it my writting different tables in different ways. A very stupid thing to
do if you ask me.

Peter Childs


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings