I'll second this sentiment.  To be honest, the curation part of the code
was implemented under a lot of tar pit fatigue—the lack of progress from
context switching costs induced intellectual laziness and just made me want
to submit something half-baked to be done with it.

When working from a fresh time series database, the curation process should
be fast and always be incrementally fast.  For folks who've acquired large
databases prior hereto, I expect curation to take a while as a first-time
cost.  Again, incremental applications reduce the pain around this.

How about a proposal like this:

1. The three of us lock ourselves in a room for one hour.

2. We spend the first 15 minutes identifying the smells around the object
sharing and lifecycle state transition models in Prom.  [Have the exemplars
ready.]

3. We spend 30 minutes discussing what a better set of patterns for the
needs would be and educating one another so that they are not extended.

4. Define concrete remediation bugs for existing problems.


2013/5/7 Bernerd Schaefer <notifications@github.com>

> In main.go:
>
> > @@ -91,6 +164,10 @@ func main() {
> >  	scrapeResults := make(chan format.Result, *scrapeResultsQueueCapacity)
> >  	ruleResults := make(chan *rules.Result, *ruleResultsQueueCapacity)
> >  	curationState := make(chan metric.CurationState, 1)
> > +	// Coprime numbers, fool!
> > +	headCompactionTimer := time.NewTicker(*headCompactionInterval)
> > +	bodyCompactionTimer := time.NewTicker(*bodyCompactInterval)
> > +	tailCompactionTimer := time.NewTicker(*tailcompactInterval)
>
> Okay, makes sense. I'm not entirely convinced it's the best way to handle
> that, but I need to think more about it (and it's a general thing we need
> to address in prometheus).
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/prometheus/prometheus/pull/228/files#r4115730>
> .
>