Tom, I clearly understand your point. I actually came from corporate market such as Verizon, Barclays... I remember very good that PostgreSQL is open source, but let's forget it for a moment. The key issue for corporate market always been a partitioning(vertical and lately horizontal). Because of that Oracle has too many types and combinations of partitions, the other vendors as well. Easy partitions maintenance (automatic, simple syntax) is very important for everybody who lives in corporate RDBMS world and not only use "DB's for free" in order to create some virtual shop. The main purpose of partitioning in my world is to store billions of rows and be able to search by date, hour or even minute as fast as possible. When you dealing with company, which has ~350.000.000 users, and you don't want to use key/value data stores: you need hash partitioned tables and hash partitioned table clusters to perform fast search and 4-6 tables join based on user phone number for example. I believe to increase PostgreSQL popularity in corporate world, to make real money from support, the next features might be: better vertical and later horizontal partitioning, columnar-oriented tables, DB freeze for NetApp/EMC snapshots and similar.
Sincerely yours, Yuri Levinsky, DBA Celltick Technologies Ltd., 32 Maskit St., Herzliya 46733, Israel Mobile: +972 54 6107703, Office: +972 9 9710239; Fax: +972 9 9710222 -----Original Message----- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Tuesday, June 25, 2013 10:33 PM To: Christopher Browne Cc: Yuri Levinsky; Robert Haas; Bruce Momjian; PostgreSQL Mailing Lists Subject: Re: [HACKERS] Hash partitioning. Christopher Browne <cbbro...@gmail.com> writes: > There would indeed be merit in improving the partitioning apparatus, > and actually, I think it's been a couple of years since there has been > serious discussion of this. We could certainly use a partitioning mechanism that's easier to use than what we have now, which is basically "build it yourself, here's the parts bin". There would also be some performance benefits from moving the partitioning logic into hard-wired code. However, I find it hard to think that hash partitioning as such is very high on the to-do list. As was pointed out upthread, the main practical advantage of partitioning is *not* performance of routine queries, but improved bulk-data management such as the ability to do periodic housecleaning by dropping a partition. If your partitioning is on a hash, you've thrown away any such advantage, because there's no real-world meaning to the way the data's been split up. So I find range and list partitioning way more plausible. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers