Re: Named vs Unnamed Partitions
От | Dimitri Fontaine |
---|---|
Тема | Re: Named vs Unnamed Partitions |
Дата | |
Msg-id | 200801092129.50376.dfontaine@hi-media.com обсуждение исходный текст |
Ответ на | Re: Named vs Unnamed Partitions (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Named vs Unnamed Partitions
|
Список | pgsql-hackers |
Hi, Le Wednesday 09 January 2008 19:27:41 Simon Riggs, vous avez écrit : > The WHERE clause approach might easily allow more than 2 chunks and they > need not be logically contiguous. So the phrase split point doesn't > really fit because it implies a one dimensional viewpoint, but I'm happy > for you to give it a name. Maybe that's only me but I'm not yet clear, after reading this thread and the previous one, whether or not Segment Exclusion would allow for multi-level partitioning. I have a use case at the moment, where we load logs-like data from several server to a central one (batch loading), the central table having an extra "server" column to identify each tuple origin. Will SE technique be able to see that this table would be better partitionned by server AND date? That's what I would have done if it was easier to do with constraint exclusion (did only date partitioning), as the reporting queries will always have some server (stats by services, each service being installed on 1 or more servers) and date restrictions. Please note I'd be happy to have this use case handled by explicitly specifying the partitioning system I want PostgreSQL to use, and more than happy if you answer me than an automatic transparent code is able to optimize the data on disk for my need without me bothering about partitions, their names and "split points"... > If we want to perform manipulations on non-read-only chunks then we need > named or numbered partitions, locking, DDL etc.. That seems like too > much functionality for what we really need. I really am still open on > that point, but I would like to see a good description of a use case > that really needs it, rather than just saying "of course we do". Which > is exactly where *I* started, even as recently as 3 weeks ago now. I like Markus ideas proposing to have SE at work inside partitions or tables, partitions being another kind of relations holding data. Then the DBA who needs to explicitly manage partitions to save faster tablespace for live data is able to tell that to the system and benefit fully from it. Regards, -- dim
В списке pgsql-hackers по дате отправления: