Re: Dynamic Partitioning using Segment Visibility Maps
От | Simon Riggs |
---|---|
Тема | Re: Dynamic Partitioning using Segment Visibility Maps |
Дата | |
Msg-id | 1199475504.18598.167.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: Dynamic Partitioning using Segment Visibility Maps (Andrew Sullivan <ajs@crankycanuck.ca>) |
Ответы |
Re: Dynamic Partitioning using Segment Visibility Maps
|
Список | pgsql-hackers |
On Fri, 2008-01-04 at 13:06 -0500, Andrew Sullivan wrote: > On Fri, Jan 04, 2008 at 01:29:55PM +0100, Markus Schiltknecht wrote: > > > > Agreed. Just a minor note: I find "marked read-only" too strong, as it > > implies an impossibility to write. I propose speaking about mostly-read > > segments, or optimized for reading or similar. > > I do want some segments to be _marked_ read-only: I want attempted writes to > them to _fail_. I think Markus thought that we would mark them read only automatically, which was not my intention. I believe its possible to have this in a way that will make you both happy. Some more explanation: There would be three different states for a segment: 1. read write 2. "optimized for reading", as Markus says it 3. marked read only by explicit command Transition 1 -> 2 is by autovacuum under the SVM proposal, transition 2 -> 3 is by user command only. So throwing an ERROR is acceptable for segments in state 3. I came up with a complex scheme for going from 1 -> 3 previously, but I don't think its needed any longer (for this, at least). It's trivial to go from 2 -> 3 using an ALTER TABLE statement, along the lines of ALTER TABLE .... WHERE .... Files that are completely in state 3 can then be archived by a hierarchical storage manager without problem. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: