Re: Dynamic Partitioning using Segment Visibility Maps
От | Markus Schiltknecht |
---|---|
Тема | Re: Dynamic Partitioning using Segment Visibility Maps |
Дата | |
Msg-id | 477EA49E.8070401@bluegap.ch обсуждение исходный текст |
Ответ на | Re: Dynamic Partitioning using Segment Visibility Maps (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Dynamic Partitioning using Segment Visibility Maps
Re: Dynamic Partitioning using Segment Visibility Maps |
Список | pgsql-hackers |
Hi, Simon Riggs wrote: > 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. Hm.. yeah, after rereading, I realize that I've mixed up states no. 2 and 3 here, sorry. >> I do want some segments to be _marked_ read-only: I want attempted writes to >> them to _fail_. Well, I can see use cases for marking tuples or complete relations as read only. But segments? I'm still puzzled about how a DBA is expected to figure out which segments to mark. Simon, are you assuming we are going to pass on segment numbers to the DBA one day? If not, a more user friendly command like "MARK READ ONLY WHERE date <= 2006" would have to move tuples around between segments, so as to be able to satisfy the split point exactly, right? > 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 Thanks for clarification. Regards Markus
В списке pgsql-hackers по дате отправления: