It won't improve performance if you know exactly what you are looking for. The goal is to improve performance when you only have a vague idea of what you want.
This isn't a place to store config files or cronned shell scripts which have definitive locations and content.
This is a replacement for that 5TB corporate filestore with a 50 directory hierarchy that nobody can figure out, and a content based find takes days to complete.
I have yet to encounter a situation where a college-level student has their home computer taken care of by a parent... quite the opposite, usually.
Agreed to the former, but the opposite isn't true either. Nobody in the family is taking care of the average home computer, hence all of the issues with the home computer:)
No it isn't. In fact, since the early 90's it has been shown continously that you will not.
Remember how big and bulky battery powered things were in the 80's? A good portion of the bulk was required due to confirming to a standard battery pack, rather than building a special one specifically for the job at hand. Another good chunk of the bulk was due to converting the voltage provided by the battery pack into the required voltage -- but we have DC to DC converters in a small enough size.
Anyway, point is, a standard laptop will cause laptops to be more bulky. Too many standard components which only rearrange in so many ways to fit the wanted form. But a freeform built in tank that fills the gaps and can be refilled from a standard connection -- possibly from a larger somewhat less portable cannister (think butane torch) would allow for standardization and an immediatly smaller form factor (batteries do not mold well).
Yeah, and I still disagree and say that long-term single projects with uncontrollable components are causing problems at NASA.
Long term goals with discrete steps are perfectly fine, but they should be known obtainable from the start without relying on advances in mostly unrelated fields like material sciences.
Fund the unrelated fields with the goal of making current components cheaper (reduced weight, increased durability). Only once Nasa has 'it', should they consider alternative ways of using it.
Your comment: the problem is that we still need to develop the cheap carbon nanotube construction methods in order to actually do it.
From the article: "The two biggest reasons that schedules slip and costs increase is that you change the requirements or you're counting on technology that didn't pan out," Smith said.
It would seem that a space elevator is exactly the thing that Nasa needs to avoid at this time. Cheaper, Better, Faster doesn't work. Cheaper with specific (possibly far reaching but obtainable) goals at a reasonable speed is a good thing to try.
Very interesting, but in the case of PostgreSQL I don't believe it will work (love to be proven wrong!). Many databases use a memory cache for speed reasons that must (of course) be in sync with the disk. Popular pages are never cleared from the cache and will not be read from disk after the initial scan.
If StarFish could tell PostgreSQL that a page it is caching is no longer valid, then this may be a possibility.
I assume StarFish guarentees TOA or 2PL or something?
Take 10k and contract out a PostgreSQL developers. Several features have been added in this way. I believe cross transaction cursors is the most recent.
I've got good news... PostgreSQL 7.4 beta 2 will reclaim index space and has a vacuum daemon in/contrib (preparation for a built in daemon).
Oracle runs vacuum as well -- it just has a different name. It's what the undo / redo logs are for, to allow MVCC while maintaining an overwriting storage manager.
You tell me how well MySQL handles the below in comparison to other DBs.
TPC-H is also about 25% writes / 75% reads on tables with billions of rows. I do hope you're not using a table lock for readers / writers. Frankly, I hope you're using some form of MVCC so writers do NOT block readers.
It also uses large parts of advanced SQL92 and SQL99 features (Subselects in the from clause being very common).
Common tricks to speed things up is to use prepared statements, compiled procedures, can be much faster than without (less network overhead, parsing, or plan generation).
If you have to explain Open Source you can explain this in terms of law too
Sure.. And right after I describe a division of the country (code fork) and that I intend to modify their laws and enforce then in that region without publishing the new laws (BSD Laws would allow this), they lock me up!
RedHat makes money by selling expertise, not pre-packaged wares. There are very few topics in the Unix world (I include Solaris & FreeBSD here) that they don't know about.
Fact of the matter is, I've even obtained quotes for supporting tools like PostgreSQL on Solaris from RedHat -- quite reasonable, and given their database team I'm sure it would have been top notch. (Company decided inhouse knowledge would be adequate -- which it probably is)
Slashdot Mirror
I see, thanks for the correction. I'm waiting for it to appear in the ports tree before I install it ;)
It won't improve performance if you know exactly what you are looking for. The goal is to improve performance when you only have a vague idea of what you want.
This isn't a place to store config files or cronned shell scripts which have definitive locations and content.
This is a replacement for that 5TB corporate filestore with a 50 directory hierarchy that nobody can figure out, and a content based find takes days to complete.
Their feature list say it will work with Oracle and other SQL99 compliant databases, so I would assume it isn't linked against libpq directly.
I have yet to encounter a situation where a college-level student has their home computer taken care of by a parent... quite the opposite, usually.
:)
Agreed to the former, but the opposite isn't true either. Nobody in the family is taking care of the average home computer, hence all of the issues with the home computer
No it isn't. In fact, since the early 90's it has been shown continously that you will not.
Remember how big and bulky battery powered things were in the 80's? A good portion of the bulk was required due to confirming to a standard battery pack, rather than building a special one specifically for the job at hand. Another good chunk of the bulk was due to converting the voltage provided by the battery pack into the required voltage -- but we have DC to DC converters in a small enough size.
Anyway, point is, a standard laptop will cause laptops to be more bulky. Too many standard components which only rearrange in so many ways to fit the wanted form. But a freeform built in tank that fills the gaps and can be refilled from a standard connection -- possibly from a larger somewhat less portable cannister (think butane torch) would allow for standardization and an immediatly smaller form factor (batteries do not mold well).
Yeah, and I still disagree and say that long-term single projects with uncontrollable components are causing problems at NASA.
Long term goals with discrete steps are perfectly fine, but they should be known obtainable from the start without relying on advances in mostly unrelated fields like material sciences.
Fund the unrelated fields with the goal of making current components cheaper (reduced weight, increased durability). Only once Nasa has 'it', should they consider alternative ways of using it.
Your comment:
the problem is that we still need to develop the cheap carbon nanotube construction methods in order to actually do it.
From the article:
"The two biggest reasons that schedules slip and costs increase is that you change the requirements or you're counting on technology that didn't pan out," Smith said.
It would seem that a space elevator is exactly the thing that Nasa needs to avoid at this time. Cheaper, Better, Faster doesn't work. Cheaper with specific (possibly far reaching but obtainable) goals at a reasonable speed is a good thing to try.
I see. Still an interesting possibility for a failover system.
TOA should have been TOW (Total ordered writes)
2PL is 2 phase locking (similar to 2pc)
Disk replication?
Very interesting, but in the case of PostgreSQL I don't believe it will work (love to be proven wrong!). Many databases use a memory cache for speed reasons that must (of course) be in sync with the disk. Popular pages are never cleared from the cache and will not be read from disk after the initial scan.
If StarFish could tell PostgreSQL that a page it is caching is no longer valid, then this may be a possibility.
I assume StarFish guarentees TOA or 2PL or something?
Take 10k and contract out a PostgreSQL developers. Several features have been added in this way. I
believe cross transaction cursors is the most recent.
Yes, eRServer available with a commercial support license support multi-slave.
:)
Multimaster will take a bit of effort.
I have interest in 2PC prior to multimaster due primarily to JBoss
I've got good news... PostgreSQL 7.4 beta 2 will reclaim index space and has a vacuum daemon in /contrib (preparation for a built in daemon).
Oracle runs vacuum as well -- it just has a different name. It's what the undo / redo logs are for, to allow MVCC while maintaining an overwriting storage manager.
Niacin is a vitamin, so it is completely safe.
Sure... Mercury is a natural mineral, so it is also completely safe to injest.
Hmm.. It's the Canadian ones with a polar bear on them right?
Excellent point. I hadn't noticed that (obviously).
Peanuts to an SBC or IBM means under 200 million. I suspect peanuts to a Novell is closer to 20million.
Ximian probably got somewhere between 3M and 5M USD (given other recent software company sales of similar size).
Of course, this is easily fixed by a binary wrapper to PHP (to do a permission check) and executing php scripts as CGIs.
Not for the high volume sites, but seems to work quite well.
You tell me how well MySQL handles the below in comparison to other DBs.
TPC-H is also about 25% writes / 75% reads on tables with billions of rows. I do hope you're not using a table lock for readers / writers. Frankly, I hope you're using some form of MVCC so writers do NOT block readers.
It also uses large parts of advanced SQL92 and SQL99 features (Subselects in the from clause being very common).
Common tricks to speed things up is to use prepared statements, compiled procedures, can be much faster than without (less network overhead, parsing, or plan generation).
Queries use for TPC-H like benchmark by OSDL. It is a pre-beta, but shows the types of queries you are dealing with.
If you have to explain Open Source you can explain this in terms of law too
Sure.. And right after I describe a division of the country (code fork) and that I intend to modify their laws and enforce then in that region without publishing the new laws (BSD Laws would allow this), they lock me up!
And prior to Microsofts purchase of Dos (and release to IBM of same) what were they up to?
Well, near bankrupt, a mostly failed unix product that took more to maintain than profit brought in. Shrinking staff (due to above).
Thats all I know. I'm sure there is a published history somewhere though.
It was certainly good enough back in '96 when I was using it on OS/2.
Why don't Americans read their own literature and
need Russian to remind them?
Russians have longer attention spans than Amer... That dog has a puffy tail! Hee hee hee hee! Here puff! Here puff!
Agreed.
RedHat makes money by selling expertise, not pre-packaged wares. There are very few topics in the Unix world (I include Solaris & FreeBSD here) that they don't know about.
Fact of the matter is, I've even obtained quotes for supporting tools like PostgreSQL on Solaris from RedHat -- quite reasonable, and given their database team I'm sure it would have been top notch. (Company decided inhouse knowledge would be adequate -- which it probably is)
Looks like it was mostly stock. See, once you're on the stock market, you have the ability to print money simply by 'creating' new stock.
The problem comes when trying to sell it, as it is only worth what the next guy will buy it for.
In reality, the deal was closer to 270 million in tangible (have it in your hands) money.