Re: Named vs Unnamed Partitions
От | Markus Schiltknecht |
---|---|
Тема | Re: Named vs Unnamed Partitions |
Дата | |
Msg-id | 4785F1A9.40008@bluegap.ch обсуждение исходный текст |
Ответ на | Re: Named vs Unnamed Partitions (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
Hi, Simon Riggs wrote: > On Wed, 2008-01-09 at 18:04 +0100, Markus Schiltknecht wrote: >> 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. Agreed. So in your terms, my question is: who does the chunking? What you are proposing with SE is that the database does the chunking automatically (based on spontaneous ordering). That's a novel and interesting idea to me. > Managing the table's files must be a manual operation. We can't infer > the presence of a new tablespace etc.. Sure. However, letting the database do the chunking (i.e. define split points), but leaving it up to the user to decide where to put those chunks certainly doesn't work. So, there are only two options: either we let the user choose split points manually, or else we tell the database those missing pieces of information and rely on automatisms. If I understand correctly, you are stating, that in the case of read-only vs read-writable, the database has enough information to make good decisions. > Those files would need less than > 10 zones or chunks, usually just one. Agreed. > 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. I consider read-only vs. read-writable to be pretty one dimensional. And the storage is logically organized in contiguous blocks. So there are split points between segments with differing read-only property, according to my definition. Regards Markus
В списке pgsql-hackers по дате отправления: