On Wed, 2007-01-10 at 15:15, Jeremy Haile wrote: > You can do list partitioning in MySQL: > http://dev.mysql.com/doc/refman/5.1/en/partitioning-list.html > > My comment was not meant as a criticism of PostgreSQL's current state - > I'm glad that it has partitioning. I'm simply wondering if there are > any plans of adopting a more user-friendly syntax in the future similar > to MySQL partitioning support. Having first-class citizen support of > partitions would also allow some nice administrative GUIs and views to > be built for managing them. I don't think anyone took it as a negative criticism. Jim and I were both more pointing out that the development process of the two projects is somewhat different. In MySQL a small group that doesn't necessarily interact with a large user community sets out to implement a feature in a given time line with a given set of requirements and they tend to ignore what they see as esoteric requirements. In PostgreSQL a large development community that communicates fairly well with it's large user community put somewhat of the onus of proving the need and doing the initial proof of concept on those who say they need a feature, often working in a method where the chief hackers lend a hand to someone who wants the feature so they can get a proof of concept up and running. And example would be the auditing / time travel in the contrib/spi project. After several iterations, and given the chance to learn from the mistakes of the previous incarnations, something often rises out of that to produce the feature needed. Generally speaking the postgresql method takes longer, making life harder today, but produces cleaner more easily maintained solutions, making life easier in the future. Meanwhile the mysql method works faster, making life easier today, but makes compromises that might make life harder in the future. Something that embodies that difference is the table handler philosophy of both databases. PostgreSQL has the abstraction to have more than one table handler, but in practice has exactly one table handler. MySQL has the ability to have many table handlers, and in fact uses many of them. With PostgreSQL this means that things like the query parsing / execution and the table handler are tightly coupled. This results in things like transactable DDL. Sometimes this results in suggestions being dismissed out of hand because they would have unintended consequences. In MySQL, because of the multiple table handlers, many compromises on the query parsing have to be made. The most common one being that you can define constraints / foreign keys in a column item, and they will simply be ignored with no error or notice. The fk constraints have to go at the end of the column list to be parsed and executed. So, partitioning, being something that will touch a lot of parts of the database, isn't gonna just show up one afternoon in pgsql. It will likely take a few people making proof of concept versions before a consensus is reached and someone who has the ability codes it up.
