Hi Robert,
Thanks all for the time you are spending commenting on this during this
busy Commit Fest.
I am not a fan of the proposed syntax. It is conceptually similar to
what we already do with constraints, but invents a whole new syntax to
no obvious benefit that I can see.
Actually I did not invent a new syntax but tried to map the Oracle
syntax which seems to be a requirement that appeared at multiple
occasions in the discussions. The question is more whether Postgres
wants to have its own syntax (and there might be good reasons for that)
or if we want to use a syntax similar to other databases for easier
migration (after all Postgres is very late on that topic compared to
other databases).
I think we would do well to look
at what other systems besides Oracle do, as well as considering any
newer ideas Oracle may have introduced. Perhaps this would be a good
thing to add to the Wiki page - instead of saying, this is the design,
say, here are some different possibilities, what do we like?
Maybe I was not clear on the intent of the wiki page. I was not trying
to pretend that this was the design but I was just trying to do my
homework on what are the issues that we will have to address (that's
basically the section headers) and I just filled the sections with what
I understood so far from the discussions, the Oracle and MySQL
documentations.
So yes, there is more work to do on understanding what other systems
besides Oracle & MySQL do, and then figuring out what we want to propose
in Postgres.
Oracle's new interval partitioning sounds great, but it ignores the
reality that most data varies considerably over time, either growing or
fluctuating. I much prefer the idea of a size-equalized partitioning
scheme, as implemented by Coppereye's Greenwich. That method gives equal
Sometimes (though certainly not always), the structure of the
underling data makes interval partitioning a win, as when for example
you are accumulating transactions that are billed at the end of each
month. If you do a lot of queries on the open transactions for the
current month, you want to make sure that there's a partition break at
the start of the month so that you're not unnecessarily scanning some
of the previous month's entries.
Partitions of similar sized are usually achieved by hash partitioning
(in both Oracle and MySQL). There are many use cases where
range/interval partitioning makes a lot of sense. One use case that was
mentioned to me is multi-level hierarchies like year->month->week->day
that would require more than 2 levels of partitioning. I think we can
think of a way of having an arbitrary depth of partitions even though
partition management might become slightly more complex/
I will try to integrate the comments as I see them on the mailing list
but feel free also to update the wiki page with your thoughts and use
cases.
Thanks again for the feedback,
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
