Re: Named vs Unnamed Partitions
От | Simon Riggs |
---|---|
Тема | Re: Named vs Unnamed Partitions |
Дата | |
Msg-id | 1199903261.4266.424.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: Named vs Unnamed Partitions (Markus Schiltknecht <markus@bluegap.ch>) |
Ответы |
Re: Named vs Unnamed Partitions
Re: Named vs Unnamed Partitions |
Список | pgsql-hackers |
On Wed, 2008-01-09 at 18:04 +0100, Markus Schiltknecht wrote: > > So not convinced of the need for named sections of tables yet. It all > > seems like detail, rather than actually what we want for managing large > > tables. > > What do you think about letting the database system know the split point > vs it having to find optimal split points automatically? For me, managing the table's files can be separate from the chunking that allows partition exclusion. Managing the table's files must be a manual operation. We can't infer the presence of a new tablespace etc.. Those files would need less than 10 zones or chunks, usually just one. The chunking to allow partition exclusion can still be automatic, allowing a much finer grain of partition. If we restrict the actions allowed to be just - mark read-only then for read-only segments (only) - migrate tablespaces - compress read-only segments - mark as off-line (not fully convinced we need this yet) then it seems straightforward to allow this to occur by a WHERE clause only, since the constraints on a segment will be fixed in place when it is read-only. This also allows those operations to take place without holding locks for any length of time, since they are all just metadata ops or copying read only data to another place. 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. 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. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: