Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL Rising

wekeroad.com

Post reply on HN
Print view View original

151–160 of 204 posts

Re: PostgreSQL Rising

#151

Post by crististm »

rickmb wrote: post #84

The primary target audience for hacker-to-hacker Postgres evangelism is MySQL users. Because let's face it, the choice for DBs like Oracle is usually made upstairs, and for very different reasons. So why do Postgres advocates insist on dissing MySQL with false and misleading arguments? The usual target is some default settings, when obviously there are three kinds of MySQL users: the ones that actually have a reason…

I, for example, have been hit these days by this: http://bugs.mysql.com/bug.php?id=26339

I wonder why this bug is still open today after 5 years.

Re: PostgreSQL Rising

#152

Post by taligent »

gaius wrote: post #148
taligent wrote: post #146

Earlier quoted context omitted.

And what about Amazon, Craigslist, eBay, Etsy, Google, Groupon, Ticketmaster, Yahoo etc. You think they are equally going to be okay with losing data ? Or do you want to try again.

Amazon runs its real-money handling on MySQL? Link please.

Nice shifting of the goalpost there.

Let's add some more companies: 37Signals, DHL, Dropbox, Evernote, UPS, Kayak, LastMinute, Orbitz, Continental, Mint, Quora, Tumblr, Techcrunch, Slashdot, NYT, NBC, Reuters, Wotif, Zappos, Wikipedia, Youtube.

You still think any of these companies would tolerate loss of ANY data for ANY reason ?

Re: PostgreSQL Rising

#153

Post by gaius »

taligent wrote: post #152
gaius wrote: post #148

Earlier quoted context omitted.

Amazon runs its real-money handling on MySQL? Link please.

Nice shifting of the goalpost there. Let's add some more companies: 37Signals, DHL, Dropbox, Evernote, UPS, Kayak, LastMinute, Orbitz, Continental, Mint, Quora, Tumblr, Techcrunch, Slashdot, NYT, NBC, Reuters, Wotif, Zappos, Wikipedia, Youtube. You still think any of these companies would tolerate loss of ANY data for ANY reason ?

Not at all. Like I say above, right tool for the job. I don't doubt that all those companies use MySQL for something, indeed probably every large company in the world has at least one instance of it somewhere.

For example, taking the first company on your list that actually deals with real stuff in the real world rather than just running a website, DHL, here I see http://www.oracle.com/us/corporate/press/037809 - they're an Oracle shop. I could continue but I think I've proved my point.

Re: PostgreSQL Rising

#154

Post by jeltz »

chris_wot wrote: post #138
juiceandjuice wrote: post #2

I'd love to move away from Oracle to Postgres, I really would. I'm trying to. But for massive amounts of data the partitioning and some other features of Oracle just work better. The partitioning is a huge thing, especially for our data which is partitioned by week then organized according to a hierarchical triangular mesh with bitmapped indexes. This works so well for us (at 8 billion rows) it's silly. MySQL couldn'…

There could be a good reason for Oracle to choose a hash join. Do you have a large table joining to a small table? Multiple processors? Setting the PGA might also be influencing optimiser... The biggest issue with Oracle is that even experts don't really know how the optimiser does something. Tuning queries in Oracle s a bit of a black art. It really shouldn't be!

In PostgreSQL tuning queries is generally quite easy once you have learned to read the EXPLAIN output. The EXPLAIN output makes it obvious most of the time why the planner chose the plan it did. This is also an area which has received improvements in every recent release. Both the explain output and the cost based planner.

Re: PostgreSQL Rising

#155

Post by zzzeek »

va_coder wrote: post #37
juiceandjuice wrote: post #24

Earlier quoted context omitted.

Yeah, there's a lot of other things we use it for. We have a lot of hierarchical data that uses the CONNECT BY statement, and I hate it because it has issues with scaling and bad execution plans, so I'm working on migrating all of that to a closure table instead.

Does Postgres have an equivalent Connect By feature? Last I checked it didn't. If you don't need to scale your hierarchical data much, its pretty handy. I'd prefer to go to Postgres too.

WITH RECURSIVE is the SQL standard version of what CONNECT BY provides with oracle. Postgresql and SQL Server both have it.

Re: PostgreSQL Rising

#156

Post by mgkimsal »

lusr wrote: post #135
mgkimsal wrote: post #127

Earlier quoted context omitted.

"... throw serious doubts on the popular myth that count( ) is slow in PostgreSQL." Whew! Glad that was only a myth! I'll remind myself of that whenever my code takes > 10 seconds to return the count( ) from a table. "Just a myth - this isn't really happening". I'll try repeating that to myself while waiting for the results - probably should only take 10-15 repeats of the phrase before the row returns, right? Whoah -…

http://wiki.postgresql.org/wiki/Slow_Counting Are there DBMSs where this doesn't happen? I just did a SELECT COUNT(*) on a table here in our QA environment; 20.5 seconds to count 42385875 records from one table and 68.8 seconds to count 191906711 records from another table (Oracle 10g 64-bit).

"The fact that multiple transactions can see different states of the data means that there can be no straightforward way for "COUNT(*)" to summarize data across the whole table; PostgreSQL must walk through all rows, in some sense."

When operating on a table, my understanding is that pg will select a version and operate on that version. If other versions are being worked on in transactions - that's a different story. Why can't metadata about the number of rows be assigned with the table version data, so after every operation, you'd know what the number of rows was at at that moment in time?

Re: PostgreSQL Rising

#158

Post by saurik »

gfodor wrote: post #102
jeffdavis wrote: post #77

Earlier quoted context omitted.

"it's a matter of reducing the complexity of migration" You put the code in your application so you can switch out the database, but why do you want to switch databases? You can't switch out the database for one with more features, because then you're not using the lowest common denominator any more, and you can't switch back. It can't be licensing costs, because postgresql licenses are free. The only other reason I…

I've seen it happen multiple times. The reasons vary, but it generally has to do with scaling up the system into more modularized components and using data stores better suited for particular sub-problems that the "big honking database" was used previously. To be clear, I'm not really suggesting you avoid using fancy features in data stores like Redis or Solr. The relational database, with history as a guide, tends t…

> using data stores better suited for particular sub-problems

Sometimes, rather than swapping out the entire data store to get access to a feature, if you cut the rope that is tying your hands behind your back you may find that your existing data store can already handle your particular sub-problem quite well, and in fact may do so better than the fancy new one that was tailored specifically for that purpose.

This happens particularly often with PostgreSQL. If you haven't used its GiST or GIN index types, you really should play around with them, and you should keep them in the same arsenal and pull them out for the same reasons you might decide to just switch everything out to Solr. A lot of the reasons people might want to use Redis are handled quite well by PostgreSQL's type extensibility.

In essence, if you are willing to throw everything out and switch to a different tool, it seems entirely inane to ignore that the tool you already have might actually already cover the features you need, especially so if the reason you are refusing to use that functionality is to make it easier for you to eventually jump ship to a tool where you no longer have your self-imposed handicap and are now willing to use the features offered.

Re: PostgreSQL Rising

#159

Post by pestaa »

jvdongen wrote: post #106
mekoka wrote: post #16

On my way to build a multi-tenant application I went through a great deal of articles recommending various architecture strategies. I was looking for an approach to organize the data for the app's various customers (multi-tenant). Most recommendations revolved around 2 solutions: 1 db per tenant, or 1 db for all tenants with a tenant_id in each table. Lucky me , I eventually stumbled upon a thread where someone menti…

I actually have implemented a multi-tenant application based on Postgres 3 years ago and we have been using it in production ever since (for paying customers that is). As such I have some experience in this field and I'm actually in the process of moving (back) to a model where each customer has its own database (and application process). For context: I have a relatively low number of tenants (tens) which in turn eac…

Considering the low number of tenants in your application, I believe automation was not an important requirement for you (if at all), but how would you go about creating virtualenvs on-the-fly?

Re: PostgreSQL Rising

#160

Post by dotborg2 »

einhverfr wrote: post #58
Roboprog wrote: post #43

Earlier quoted context omitted.

At least with PostgreSQL, most of the features are really shortcuts, rather than kludges masquerading as features. E.g. - extending a table as if it were a superclass, rather than creating a supplemental "joiner" table and creating a writeable view on top of the "super" table + the "sub" table.

I wouldn't consider them shortcuts. I use table inheritance as an actual sort of inheritance, to enforce a consistent interface over a set of relations. Yes, that could be a shortcut but it also allows for foreign keys to be against different relations on each of the partitions. Yes, that could be done with partitioning in other ways, so maybe the short cut analogy works. But others? I don't know. The ability to writ…

table inheritance is cool, but it's also incomplete, docs are pretty clear on that
Post reply on HN