Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
От | Robert Haas |
---|---|
Тема | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 |
Дата | |
Msg-id | 603c8f070811270507i36e18e0bu5d461a4f957e24d3@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1
Re: Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1 |
Список | pgsql-hackers |
On Thu, Nov 27, 2008 at 7:04 AM, Alvaro Herrera <alvherre@commandprompt.com> 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
В списке pgsql-hackers по дате отправления: