On Thu, Nov 27, 2008 at 7:04 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Nikhil Sontakke escribió: > >> The status has always being WIP, because what has not happened is that we >> have not had consensus on whether this is a logical first baby step ahead >> with partitioning. I haven't seen core members commenting on whether trying >> to aggregate the current set of manual operations together via this approach >> is worth spending further efforts, to get it into commitable shape. > > There was a lenghty, interesting discussion about this topic in the > developer meeting in Ottawa. > http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting#Partitioning_Roadmap
Interesting - too bad there aren't some mode detailed notes. The semantics of PARTITION ON (<expr>) are unclear to me. I was thinking maybe it would make sense to do something like: CREATE PARTITION <name> ON <table> WHERE <expr> Then you could: CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date BETWEEN '2008-11-01' AND '2008-11-30'; I like the idea of using table inheritance as a foundation for this feature, but I think it's not going to be very useful for real-world applications without cross-table indexes. Suppose for example that I have five years worth of data (thus, 60 partitions) and each transaction has a unique identifier of some sort that is unrelated to the date. It's bad enough that a query like this has to check every partition: SELECT * FROM transaction WHERE uuid = ? What's even worse (at least IMHO) is that there's no way to use transaction (uuid) as a reference for a foreign key. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
