For six months, I couldn't sleep. With insomnia, nothing's real. Everything's far away. Everything's a copy of a copy of a copy. When you have insomnia, you're never really asleep, and you're never really awake.
GP probably just does what I do when I'm on a WoW marathon: pee into an empty 3-Liter of Mountain Dew next to the gaming chair. Don't want to take any risks, right?
(Only problem is sometimes when I get my Dew bottles mixed up.. Yecch!)
It sounds like you want to use PostgreSQL as something like a (non-durable) cache layer. I'm not sure anyone has tried removing WAL entirely from the system, but people have definitely played around with the idea. See e.g. here. With a little tweaking, you should be able to get a large speedup by sacrificing durability/crash recovery.
Well, the GP was probably asking more about materialized views integrated into the Postgres core itself (I think Oracle has these). So that you could materialize an existing view just by saying "CREATE MATERIALIZED VIEW... ", instead of cooking up the triggers yourself.
Now, The page you linked to actually says:
I do not recommend that PostgreSQL add Materialized Views in its core.
As for the GP's gripe about "those two ridiculously huge undo-type files", I have no idea what he's smoking. Postgres's "undo-type" files are its WAL logs, and you can configure how many it keeps around. They are 16 MB each by default. I've had no problem running Postgres on tiny hardware (cheap VPSes), and it comes configured out of the box to do just fine on minimal hardware.
"Real Work"? What's that? MySQL was for a very long time the DB used by adsense and youtube...
Uh-huh. That's because if Youtube loses a video of a cat with 3 views, who gives a flying fuck? Ask your bank or your credit card company what database they use to store their financial transactions. Probably won't be PostgreSQL, but it sure as hell won't be MySQL. And they're only using Oracle because $10M to them is chump change.
Re:Waiting for a capable PostgreSQL front-end
on
PostgreSQL 9.0 Released
·
· Score: 2, Informative
Indeed. About 0.0005 seconds of Googling brought me this as the first link:
Eh? Not sure exactly what you mean, but the postgres documentation is built from SGML into several formats, such as a giant PDF or the web documentation. It's pretty darn good, and if you have quibbles with any of it, post to pgsql-docs and you'll have someone on the case pretty quickly.
Replying to myself, I just remembered another interesting option that came up recently: you could also use the $40/month Virgin Mobile hotspot, along with an Android phone + sipdroid + google voice, and have unlimited 3G data and voice everywhere plus your own hotspot. How cool is that?
Mod parent up. The Wal-Mart deal isn't actually that good, considering the offerings from Virgin Mobile, and Cricket. Not to mention Boost Mobile ($50 for unlimited everything, last I checked) and Metro PCS (similar unlimited pricing).
Personally, I keep my cell phone bill down around $10/month using prepaid minutes from T-Mobile. I've got an Android phone (G1, only $100 on eBay) and I can use sipdroid on it, combined with Google Voice and a free POTS->SIP accounts, for free minutes when I'm on wifi, which is most of the time.
Just stay the fuck away from AT&T and the other gorillas trying to lock you into overpriced 2-year plans and you'll do fine. Cell prices are finally coming down.
We need to learn to better respect the blue collar jobs. Without people doing those jobs our world doesn't work, yet people are taught from a young age that doing blue-collar work is something you should work to avoid.
Just throwing a relevant article recommendation, based on a book which is also a good read: Matthew Crawford's The Case for Working With Your Hands, based on the book Shop Class as Soulcraft. There is a puzzling bias against any blue-collar work in this country, regardless of how challenging or well-paying it may be. Ever look at the hourly rate your plumber charges? Or how much fun it might be to, say, work on cars or motorcycles for a living as compared to banging out TPS Reports?
Speak to your government about the enormous taxes they pile on top of that price.
I don't see why it' so terrible to pay gasoline taxes. We are dumping pollutants into the air with our cars, using the roads which our government funds, causing obnoxious noise and traffic jams...
I was just in Cuenca, Ecuador, where gas is $1.50 / gallon. The pollution from cars and buses in the city is unbearable: you can barely stand to walk around the city. Of course, hardly anyone walks anywhere, since a taxi anywhere within the city is a flat $2. The pollution is a real shame, since the city is situated in a picturesque valley tucked in the Andes mountains.
but what if you have two clients get the MAX(pkey_column) at the same time? wouldn't they both be inserting the same key?
Yup. Look up SELECT... FOR UPDATE for your database for the answer to your question, though again the real solution is just to use the appropriate sequence type provided by your RDBMS and let it do the work for you.
Imagine that you still have a single point of failure if your big expensive database server goes down.
Not true, if you set things up properly. Look up STONITH -- it's quite easy to quickly turn a slave into the new master if your master dies (so long as you are sure the master is dead, and you can decide which slave to promote!).
And those queries return incorrect results when they are behind the master. Pretty cool, huh?
Yup, that's the idea behind "asynchronous replication", and that's exactly how it's billed. If that's a deal-killer for you (for a large number of read-only queries it won't be.. think web applications where an eventually consistent state is perfectly fine) just wait until Postgres 9.1, when we should have more knobs for controlling master-slave replication. Then you should have the option to force the master to wait until a slave has received its WAL file update, and even fsync'ed it to disk, before your COMMIT returns, giving you the synchronous replication behavior you want.
The tradeoff with synchronous replication is increased latency on the master of course, since you're hanging around waiting for the slave to fsync (or just receive the data, depending on how you turn the knob). There have even been some proposals floating around for a "quorum commit" model whereby you would tell the master that you want your COMMIT; to go through when n out of m slaves have received the data.
Eh? When was multi-master replication ever promised in core? You're probably thinking about hot standby -- the Streaming Replication/Hot Standby code which is the "killer feature" of 9.0 was originally slated for 8.4, but didn't make it in time. I'm really surprised there aren't more comments about SR/HS, as it's an awesome feature which lets Postgres compete with the big boys like Oracle.
Imagine having your expensive database server be dedicated *only* to writes, and having all your read-only queries spread across one or more slave(s) which are also your backup servers. Pretty cool, huh?
Some things they just don't *want* to implement on ideological reasons, like "UPDATE OR INSERT" or "CREATE IF NOT EXISTS" in PostgreSQL at least.
Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here:
And work on MERGE support is itself blocked behind the fact that PostgreSQL doesn't have a good way to lock access to a key value that doesn't exist yet--what other databases call key range locking. See the notes for "Add SQL-standard MERGE/REPLACE/UPSERT command" at http://wiki.postgresql.org/wiki/Todo for more information.
Your gripe about CREATE... IF NOT EXISTS might hold water, depending on what exactly you're complaining about (CREATE TABLE? Or for indexes/constraints?). There does seem to be some resistance to CINE, though from what I can tell it's mostly because people would rather have CREATE OR REPLACE, but COR is much harder to implement (what do you do when the object already exists, but is slightly different than the one you're trying to create)?
You're basically describing the SQL language itself (PostgreSQL does a good job of implementing most of the various SQL standards up to SQL-92 and even SQL-99). Of course, add-on procedural languages like Oracle's PL/SQL aren't going to be supported as-is anytime soon on PostgreSQL, or anywhere else. And of course, each database vendor has their own extensions to the SQL language itself, which other vendors aren't always keen to copy (think MySQL's INSERT... ON DUPLICATE KEY UPDATE, or PostgreSQL's CLUSTER).
If you're designing a database application which you want to be easily portable across various SQL databases, just try to keep any non-standard-SQL use to a minimum and use of procedural languages simple and only when necessary. Books by Joe Celko stress this ideology, though my take is that it's just about impossible to really get the most out of your database unless you really make use of its extensions, which are there for a reason. For example, Celko discourages the use of auto-increment columns (serial type in Postgres, auto-increment primary key in MySQL), in favor of manually incrementing your sequence using MAX(pkey_column) or similar, which strikes me as absurd and non-scalable.
Now, save the file you just created as "/tmp/botnet.py". Run "chmod a+x/tmp/botnet.py", and then run "sudo/tmp/botnet.py". Oh, and you'll have to install the "botnet" Python module first.. you should be able to find it in the Cheeseshop, or if you're on Debian/Ubuntu, just run "sudo apt-get install python-botnet". Thanks for doing your part to make MS Windows obsolete!
Make the link to the "demo" front and center. Forget about "screenshots" -- it's a web application, who wants to see screenshots when you can click a link and see the web app in action!
Let people using Enano send in a link (or edit a wiki page of links) linking to their homepage. This will give end-users with tiny sites an incentive to try your package, because it will drive traffic to them. Long ago, I used a CMS called Serendipity that had exactly this marketing tactic, and it worked well.
Uh.. you really need themes available. Think of myspace, etc. People like to customize their sites.
Mr Goodnight considers [free meals for employees] unwise, for tax reasons: “I keep telling Larry and Sergey you shouldn’t give away food—the IRS will come in.”
I've often wondered how Google gets away with free meals every day and other generous perks for employees, and not making the employees declare the free food as "income" to the IRS and pay taxes on it.
Probably the only defense against this kind of abuse are one time credit cards but even then your credit score could take a bashing.
Video Professor and others are wise to the one-time use credit cards (e.g. the prepaid "Vanilla Visa" or Amexes you can get at drugstores) and simply reject them outright nowadays. I suspect that the credit cards which let you generate one-time use codes would work, but I've also heard various reports on SlickDeals about multiple charges successfully posting to such numbers which are supposed to be one-time use only.
A few years ago, there was a bubble of freeipod-type ponzi schemes which were backed by "trial" offers from Video Professor and others. Pretty much the only way you could be sure you wouldn't be stuck with enormous charges was by using a fake name, fake address, and prepaid gift card for all transactions. Don't ask me how I know this.
If you have an infinite supply of money, then you can always win in the long run, but you can only win a small amount. The strategy for doing this is to double your bet every time, and eventually you make a profit of your initial stake. Then you stop playing.
Just in case anyone read the parent post, and thought it sounded like a good betting strategy, a few points:
This strategy is well-known and analyzed: see Martingale Betting System on wikipedia for the full story.
Another word for these and similar strategies (e.g. currency carry trades) is "picking up nickels in front of a steamroller".
If you have "an infinite amount of money", and want to make a finite return, stick it in a bank account. This even works with a finite principal!
If you want to gamble, buy stocks. Don't go to Vegas.
Slashdot Mirror
For six months, I couldn't sleep. With insomnia, nothing's real. Everything's far away. Everything's a copy of a copy of a copy. When you have insomnia, you're never really asleep, and you're never really awake.
The USPS, government run, government owned, government controlled, no competition in the mail business by law. How is that for you?
Uh-huh. And established in the US Constitution. Great example for the GP's claim that we're not any more socialistic now than 10 years ago.
GP probably just does what I do when I'm on a WoW marathon: pee into an empty 3-Liter of Mountain Dew next to the gaming chair. Don't want to take any risks, right?
(Only problem is sometimes when I get my Dew bottles mixed up.. Yecch!)
It sounds like you want to use PostgreSQL as something like a (non-durable) cache layer. I'm not sure anyone has tried removing WAL entirely from the system, but people have definitely played around with the idea. See e.g. here. With a little tweaking, you should be able to get a large speedup by sacrificing durability/crash recovery.
Well, the GP was probably asking more about materialized views integrated into the Postgres core itself (I think Oracle has these). So that you could materialize an existing view just by saying "CREATE MATERIALIZED VIEW ... ", instead of cooking up the triggers yourself.
Now, The page you linked to actually says:
I do not recommend that PostgreSQL add Materialized Views in its core.
because of their inherent complexity and customizable nature. There actually has been some work recently attempting to do just this: see e.g. http://archives.postgresql.org/pgsql-hackers/2010-04/msg00479.php.
As for the GP's gripe about "those two ridiculously huge undo-type files", I have no idea what he's smoking. Postgres's "undo-type" files are its WAL logs, and you can configure how many it keeps around. They are 16 MB each by default. I've had no problem running Postgres on tiny hardware (cheap VPSes), and it comes configured out of the box to do just fine on minimal hardware.
"Real Work"? What's that? MySQL was for a very long time the DB used by adsense and youtube...
Uh-huh. That's because if Youtube loses a video of a cat with 3 views, who gives a flying fuck? Ask your bank or your credit card company what database they use to store their financial transactions. Probably won't be PostgreSQL, but it sure as hell won't be MySQL. And they're only using Oracle because $10M to them is chump change.
Indeed. About 0.0005 seconds of Googling brought me this as the first link:
http://www.postgresonline.com/journal/archives/24-Using-MS-Access-with-PostgreSQL.html
Though I think there are probably a grand total of 3 people on Earth who have used MS Access in any serious capacity and don't loathe it.
The documentation just links to web pages
Eh? Not sure exactly what you mean, but the postgres documentation is built from SGML into several formats, such as a giant PDF or the web documentation. It's pretty darn good, and if you have quibbles with any of it, post to pgsql-docs and you'll have someone on the case pretty quickly.
Replying to myself, I just remembered another interesting option that came up recently: you could also use the $40/month Virgin Mobile hotspot, along with an Android phone + sipdroid + google voice, and have unlimited 3G data and voice everywhere plus your own hotspot. How cool is that?
Mod parent up. The Wal-Mart deal isn't actually that good, considering the offerings from Virgin Mobile, and Cricket. Not to mention Boost Mobile ($50 for unlimited everything, last I checked) and Metro PCS (similar unlimited pricing).
Personally, I keep my cell phone bill down around $10/month using prepaid minutes from T-Mobile. I've got an Android phone (G1, only $100 on eBay) and I can use sipdroid on it, combined with Google Voice and a free POTS->SIP accounts, for free minutes when I'm on wifi, which is most of the time.
Just stay the fuck away from AT&T and the other gorillas trying to lock you into overpriced 2-year plans and you'll do fine. Cell prices are finally coming down.
Just throwing a relevant article recommendation, based on a book which is also a good read: Matthew Crawford's The Case for Working With Your Hands, based on the book Shop Class as Soulcraft. There is a puzzling bias against any blue-collar work in this country, regardless of how challenging or well-paying it may be. Ever look at the hourly rate your plumber charges? Or how much fun it might be to, say, work on cars or motorcycles for a living as compared to banging out TPS Reports?
I don't see why it' so terrible to pay gasoline taxes. We are dumping pollutants into the air with our cars, using the roads which our government funds, causing obnoxious noise and traffic jams...
I was just in Cuenca, Ecuador, where gas is $1.50 / gallon. The pollution from cars and buses in the city is unbearable: you can barely stand to walk around the city. Of course, hardly anyone walks anywhere, since a taxi anywhere within the city is a flat $2. The pollution is a real shame, since the city is situated in a picturesque valley tucked in the Andes mountains.
but what if you have two clients get the MAX(pkey_column) at the same time? wouldn't they both be inserting the same key?
Yup. Look up SELECT ... FOR UPDATE for your database for the answer to your question, though again the real solution is just to use the appropriate sequence type provided by your RDBMS and let it do the work for you.
Imagine that you still have a single point of failure if your big expensive database server goes down.
Not true, if you set things up properly. Look up STONITH -- it's quite easy to quickly turn a slave into the new master if your master dies (so long as you are sure the master is dead, and you can decide which slave to promote!).
And those queries return incorrect results when they are behind the master. Pretty cool, huh?
Yup, that's the idea behind "asynchronous replication", and that's exactly how it's billed. If that's a deal-killer for you (for a large number of read-only queries it won't be.. think web applications where an eventually consistent state is perfectly fine) just wait until Postgres 9.1, when we should have more knobs for controlling master-slave replication. Then you should have the option to force the master to wait until a slave has received its WAL file update, and even fsync'ed it to disk, before your COMMIT returns, giving you the synchronous replication behavior you want.
The tradeoff with synchronous replication is increased latency on the master of course, since you're hanging around waiting for the slave to fsync (or just receive the data, depending on how you turn the knob). There have even been some proposals floating around for a "quorum commit" model whereby you would tell the master that you want your COMMIT; to go through when n out of m slaves have received the data.
Eh? When was multi-master replication ever promised in core? You're probably thinking about hot standby -- the Streaming Replication/Hot Standby code which is the "killer feature" of 9.0 was originally slated for 8.4, but didn't make it in time. I'm really surprised there aren't more comments about SR/HS, as it's an awesome feature which lets Postgres compete with the big boys like Oracle.
Imagine having your expensive database server be dedicated *only* to writes, and having all your read-only queries spread across one or more slave(s) which are also your backup servers. Pretty cool, huh?
Some things they just don't *want* to implement on ideological reasons, like "UPDATE OR INSERT" or "CREATE IF NOT EXISTS" in PostgreSQL at least.
Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here:
Your gripe about CREATE ... IF NOT EXISTS might hold water, depending on what exactly you're complaining about (CREATE TABLE? Or for indexes/constraints?). There does seem to be some resistance to CINE, though from what I can tell it's mostly because people would rather have CREATE OR REPLACE, but COR is much harder to implement (what do you do when the object already exists, but is slightly different than the one you're trying to create)?
You're basically describing the SQL language itself (PostgreSQL does a good job of implementing most of the various SQL standards up to SQL-92 and even SQL-99). Of course, add-on procedural languages like Oracle's PL/SQL aren't going to be supported as-is anytime soon on PostgreSQL, or anywhere else. And of course, each database vendor has their own extensions to the SQL language itself, which other vendors aren't always keen to copy (think MySQL's INSERT ... ON DUPLICATE KEY UPDATE, or PostgreSQL's CLUSTER).
If you're designing a database application which you want to be easily portable across various SQL databases, just try to keep any non-standard-SQL use to a minimum and use of procedural languages simple and only when necessary. Books by Joe Celko stress this ideology, though my take is that it's just about impossible to really get the most out of your database unless you really make use of its extensions, which are there for a reason. For example, Celko discourages the use of auto-increment columns (serial type in Postgres, auto-increment primary key in MySQL), in favor of manually incrementing your sequence using MAX(pkey_column) or similar, which strikes me as absurd and non-scalable.
Check out "bit9" if you're interested in application whitelisting. Haven't used them myself, so I can't vouch for them, but seems like a good idea.
Good luck running PERL or Python on a windows machine without finding a way to install either on the system first ;)
Pah. Who needs Windows machines for a botnet? Look, I can start my own botnet right here with a few lines of Python:
Dear Slashdot readers on *nix machines. Please fire up vi, copy and paste the following text:
#!/usr/bin/python
import socket
import botnet
botnet.connect()
botnet.identify(socket.gethostname())
botnet.accept_control_commands()
Now, save the file you just created as "/tmp/botnet.py". Run "chmod a+x /tmp/botnet.py", and then run "sudo /tmp/botnet.py". Oh, and you'll have to install the "botnet" Python module first.. you should be able to find it in the Cheeseshop, or if you're on Debian/Ubuntu, just run "sudo apt-get install python-botnet". Thanks for doing your part to make MS Windows obsolete!
From taking a 10-second look at the :
Interesting snippet from that article:
Mr Goodnight considers [free meals for employees] unwise, for tax reasons: “I keep telling Larry and Sergey you shouldn’t give away food—the IRS will come in.”
I've often wondered how Google gets away with free meals every day and other generous perks for employees, and not making the employees declare the free food as "income" to the IRS and pay taxes on it.
... observe reality in its full high-definion glory, ...
Cool! Do you have some of these sunglasses too!?!?
Probably the only defense against this kind of abuse are one time credit cards but even then your credit score could take a bashing.
Video Professor and others are wise to the one-time use credit cards (e.g. the prepaid "Vanilla Visa" or Amexes you can get at drugstores) and simply reject them outright nowadays. I suspect that the credit cards which let you generate one-time use codes would work, but I've also heard various reports on SlickDeals about multiple charges successfully posting to such numbers which are supposed to be one-time use only.
A few years ago, there was a bubble of freeipod-type ponzi schemes which were backed by "trial" offers from Video Professor and others. Pretty much the only way you could be sure you wouldn't be stuck with enormous charges was by using a fake name, fake address, and prepaid gift card for all transactions. Don't ask me how I know this.
If you have an infinite supply of money, then you can always win in the long run, but you can only win a small amount. The strategy for doing this is to double your bet every time, and eventually you make a profit of your initial stake. Then you stop playing.
Just in case anyone read the parent post, and thought it sounded like a good betting strategy, a few points:
If you want to gamble, buy stocks. Don't go to Vegas.