8.0.X and the ARC patent

Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.

There is an advantage beyond just not having to re-write the code, but it
would also be sort of an IBM blessing, great PR.

I will be at "Linux World" and see if there is an IBM booth, maybe I can
get some contact info.

pgsql@mohawksoft.com wrote:

Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.

There is an advantage beyond just not having to re-write the code, but it
would also be sort of an IBM blessing, great PR.

I will be at "Linux World" and see if there is an IBM booth, maybe I can
get some contact info.

I doubt they will give us something that extends to companies that sell
PostgreSQL so I don't see the point.

---------------------------------------------------------------------------

FYI, core has discussed the pending IBM ARC patent and the usage of
those ideas in 8.0.

Tom has found a 2Q cache algorithm that predates the ARC patent and is
very similar to ARC. The major difference is that it doesn't auto-size
the ARC sub-buffers.

Core believes it is best to backpatch this 2Q algorithm into 8.0.X to
avoid any possible patent problems if the patent is granted and
enforced.

We are testing the use of the 2Q code to see if it has any performance
impact. The 8.0.X release that uses 2Q will have more extensive testing
than a normal minor release. 8.1 will have a new cache algorithm that
hopefully will remove the buffer contention problems experienced by SMP
machines.

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

--
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

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

http://www.postgresql.org/docs/faq

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

-- 
  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

pgsql@mohawksoft.com wrote:

Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.

There is an advantage beyond just not having to re-write the code, but
it
would also be sort of an IBM blessing, great PR.

I will be at "Linux World" and see if there is an IBM booth, maybe I can
get some contact info.

I doubt they will give us something that extends to companies that sell
PostgreSQL so I don't see the point.

Actually, I think that's wrong. IBM has been really gung-ho about Linux.
Of course this is an obvious movement against Microsoft domination of the
server market, but they have made some very strong open source statements
and have release about 500 patents to open source projects.

The current open source patents extend to companies that sell other
products, why not PostgreSQL as well?

There is a *LOT* of crap going on with patents, there are so many issues
and motives that is hard to keep track of why who is doing what. My bet is
that it is 50/50. It all depends if IBM wants to hurt Oracle more than it
wants to defned DB2.

Bruce Momjian wrote:

pgsql@mohawksoft.com wrote:

Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.

There is an advantage beyond just not having to re-write the code, but it
would also be sort of an IBM blessing, great PR.

I will be at "Linux World" and see if there is an IBM booth, maybe I can
get some contact info.

I doubt they will give us something that extends to companies that sell
PostgreSQL so I don't see the point.

Also if I recall didn't Tom already have a patch ready to be
tested for the q2 stuff?

Sincerely,

Joshua D. Drake

---------------------------------------------------------------------------

FYI, core has discussed the pending IBM ARC patent and the usage of
those ideas in 8.0.

Tom has found a 2Q cache algorithm that predates the ARC patent and is
very similar to ARC. The major difference is that it doesn't auto-size
the ARC sub-buffers.

Core believes it is best to backpatch this 2Q algorithm into 8.0.X to
avoid any possible patent problems if the patent is granted and
enforced.

We are testing the use of the 2Q code to see if it has any performance
impact. The 8.0.X release that uses 2Q will have more extensive testing
than a normal minor release. 8.1 will have a new cache algorithm that
hopefully will remove the buffer contention problems experienced by SMP
machines.

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

--
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

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

http://www.postgresql.org/docs/faq

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

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Joshua D. Drake wrote:

Bruce Momjian wrote:

pgsql@mohawksoft.com wrote:

Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.

There is an advantage beyond just not having to re-write the code, but it
would also be sort of an IBM blessing, great PR.

I will be at "Linux World" and see if there is an IBM booth, maybe I can
get some contact info.

I doubt they will give us something that extends to companies that sell
PostgreSQL so I don't see the point.

Also if I recall didn't Tom already have a patch ready to be
tested for the q2 stuff?

Yes, he does.

-- 
  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

pgsql@mohawksoft.com writes:

Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.

If there were hard evidence that the ARC algorithm was far better than
the alternatives, it might be worth going in that direction. But there
is no such evidence. Jan has retracted his original opinion that the
ARC code is a big improvement over what we had before, and I haven't
seen anyone else putting up benchmark numbers that say we need to keep
ARC.

regards, tom lane

Tom Lane wrote:

pgsql@mohawksoft.com writes:

Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.

If there were hard evidence that the ARC algorithm was far better than
the alternatives, it might be worth going in that direction. But there
is no such evidence. Jan has retracted his original opinion that the
ARC code is a big improvement over what we had before, and I haven't
seen anyone else putting up benchmark numbers that say we need to keep
ARC.

And ARC has locking requirements that will make it very hard to fix our
SMP buffer management problems in 8.1.

-- 
  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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

And ARC has locking requirements that will make it very hard to fix our
SMP buffer management problems in 8.1.

I am working on a buffer manager rewrite using the BufMgrLock breakup
and "clock sweep" management algorithm we've been discussing. At the
moment it's passing the regression tests but I'm sure there's some bugs
left :-(. I just now tried it on the infamous context-swap-storm test
case using a 4-way machine at Red Hat. PG 8.0 shows 20K or more CS/sec
and under 30% CPU usage in this situation. The patch shows 99% CPU
utilization and about 200 CS/sec (which is about nil, because the
machine shows ~100 CS/sec with nothing running except vmstat).

Still to be determined: what we lose in extra I/O from the presumably
less efficient cache management; also what sort of slowdown occurs on
a single-CPU machine that isn't going to get any benefit from the
increased amount of lock management. But it looks promising.

regards, tom lane

pgsql@mohawksoft.com wrote:

pgsql@mohawksoft.com wrote:

Might it be possible to contact IBM directly and ask if they will allow
usage of the patent for PostgreSQL. They've let 500 patents for open
source, maybe they'll give a write off for this as well.

There is an advantage beyond just not having to re-write the code, but
it
would also be sort of an IBM blessing, great PR.

I will be at "Linux World" and see if there is an IBM booth, maybe I can
get some contact info.

I doubt they will give us something that extends to companies that sell
PostgreSQL so I don't see the point.

Actually, I think that's wrong. IBM has been really gung-ho about Linux.
Of course this is an obvious movement against Microsoft domination of the
server market, but they have made some very strong open source statements
and have release about 500 patents to open source projects.

The current open source patents extend to companies that sell other
products, why not PostgreSQL as well?

There is a *LOT* of crap going on with patents, there are so many issues
and motives that is hard to keep track of why who is doing what. My bet is
that it is 50/50. It all depends if IBM wants to hurt Oracle more than it
wants to defned DB2.

Seeing up close what IBM is doing with Eclipse, I must concur with this.
I would be surprised if they said no. IBM knows that making revenue from
software licenses is becoming increasingly harder. My impression is that
they want to become less dependent on that and instead become more
services oriented. This patent was filed before they started to change
direction big time. Personally, I don't think they would care about it
at all now.

So IMHO, ask IBM. It can't hurt.

Regards,
Thomas Hallgren

Tom Lane wrote:

Still to be determined: what we lose in extra I/O from the presumably
less efficient cache management; also what sort of slowdown occurs on
a single-CPU machine that isn't going to get any benefit from the
increased amount of lock management. But it looks promising.

Yea, that was one of my questions --- the new buffer locking helps SMP,
but how much does it hurt single-cpu machines? Do we need autodetection
or a GUC to control SMP-beneficial locking?

-- 
  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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Still to be determined: what we lose in extra I/O from the presumably
less efficient cache management; also what sort of slowdown occurs on
a single-CPU machine that isn't going to get any benefit from the
increased amount of lock management. But it looks promising.

Yea, that was one of my questions --- the new buffer locking helps SMP,
but how much does it hurt single-cpu machines?

So far I've not been able to measure any consistent difference, but you
know how much I trust pgbench ;-). I hope that Mark Wong can give us
some results on the OSDL setup soon.

regards, tom lane

On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

Might we set a rough date for Beta freeze for 8.1 then?

September 30th 2005 ?

I see only benefit from publishing a not-before date now. It's up to
Core if it slips, but it'll really help with gaining funding if people
can accurately determine whether or not features can be added for
inclusion in the next release. There are lots of potential donors
waiting, so lets give them some certainty about which release their
payback will occur in....

Best Regards, Simon Riggs

Simon Riggs wrote:

On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

Might we set a rough date for Beta freeze for 8.1 then?

September 30th 2005 ?

I see only benefit from publishing a not-before date now. It's up to
Core if it slips, but it'll really help with gaining funding if people
can accurately determine whether or not features can be added for
inclusion in the next release. There are lots of potential donors
waiting, so lets give them some certainty about which release their
payback will occur in....

Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.

-- 
  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, 25 Feb 2005, Bruce Momjian wrote:

Simon Riggs wrote:

On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

Might we set a rough date for Beta freeze for 8.1 then?

September 30th 2005 ?

I see only benefit from publishing a not-before date now. It's up to
Core if it slips, but it'll really help with gaining funding if people
can accurately determine whether or not features can be added for
inclusion in the next release. There are lots of potential donors
waiting, so lets give them some certainty about which release their
payback will occur in....

Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.

I thought we were looking at a 12-18 month cycle for 8.1? Which would put
beta around January '06, no?

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

On Fri, 2005-02-25 at 00:18 -0500, Bruce Momjian wrote:

Simon Riggs wrote:

On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

Might we set a rough date for Beta freeze for 8.1 then?

September 30th 2005 ?

I see only benefit from publishing a not-before date now. It's up to
Core if it slips, but it'll really help with gaining funding if people
can accurately determine whether or not features can be added for
inclusion in the next release. There are lots of potential donors
waiting, so lets give them some certainty about which release their
payback will occur in....

Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.

[Sorry, just brought this up as part of another more general thread.]

That's fine. Just have two (rough dates):

- Major Feature Design Freeze - June 2005 (or 2Q2005)
Major features may require significant discussion, prototyping and
performance testing before agreement to include. You are advised that
major features presented for initial code review may not be accepted
after this date.

- Overall Feature Freeze - Sept 2005 (or 3Q2005)
All code implementing new features, large or small, should be complete
by this date. Features may be rejected if supporting tests and
documentation are not provided.

Best Regards, Simon Riggs

On Fri, 2005-02-25 at 02:47 -0400, Marc G. Fournier wrote:

On Fri, 25 Feb 2005, Bruce Momjian wrote:

Simon Riggs wrote:

On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

Might we set a rough date for Beta freeze for 8.1 then?

September 30th 2005 ?

I see only benefit from publishing a not-before date now. It's up to
Core if it slips, but it'll really help with gaining funding if people
can accurately determine whether or not features can be added for
inclusion in the next release. There are lots of potential donors
waiting, so lets give them some certainty about which release their
payback will occur in....

Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.

I thought we were looking at a 12-18 month cycle for 8.1? Which would put
beta around January '06, no?

I'm happy with Core taking this decision, I'd just like to know +/- 1
month when that date is, i.e. which quarter of which year.

Best Regards, Simon Riggs

Bruce Momjian wrote:

Simon Riggs wrote:

On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

Might we set a rough date for Beta freeze for 8.1 then?

September 30th 2005 ?

I see only benefit from publishing a not-before date now. It's up to
Core if it slips, but it'll really help with gaining funding if people
can accurately determine whether or not features can be added for
inclusion in the next release. There are lots of potential donors
waiting, so lets give them some certainty about which release their
payback will occur in....

Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.

Am I misunderstanding here? September 30th is 15 months after the
feature freeze for 8.0. On that basis we might reasonably expect 8.1 to
appear around April 2006. Is that what's intended?

cheers

andrew

Marc G. Fournier wrote:

On Fri, 25 Feb 2005, Bruce Momjian wrote:

Simon Riggs wrote:

On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:

For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.

Might we set a rough date for Beta freeze for 8.1 then?

September 30th 2005 ?

I see only benefit from publishing a not-before date now. It's up to
Core if it slips, but it'll really help with gaining funding if people
can accurately determine whether or not features can be added for
inclusion in the next release. There are lots of potential donors
waiting, so lets give them some certainty about which release their
payback will occur in....

Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.

I thought we were looking at a 12-18 month cycle for 8.1? Which would put
beta around January '06, no?

Oh, yea. I didn't realize people agreed with that, but I certainly
agree.

So that would put us at January. Simon, I think the major issue is how
much does it help us to fix a date now vs. what is the benefit to
allowing us to state it later.

-- 
  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

"Marc G. Fournier" <scrappy@postgresql.org> writes:

Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.

I thought we were looking at a 12-18 month cycle for 8.1? Which would put
beta around January '06, no?

Although we've dropped the idea of letting the ARC problem drive a very
short 8.1 cycle, I would still like to see us shoot for a relatively
short 8.1 cycle --- less than a year for sure. The main reason is that
I think we'll be flushing out performance and feature issues in the
Windows port that we cannot reasonably back-patch into 8.0.*. PITR also.
In general it seems to me that 8.1 will need to have a consolidation and
fill-in-the-blanks flavor after what we did for 8.0, and that will be
helped by a shorter devel cycle.

As a proposal: feature freeze maybe early summer (June or July), beta
maybe Aug/Sep, final as always "when it's ready" (maybe Oct/Nov with
a good tailwind).

regards, tom lane