<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Redo over multiple weeks</title>
	<atom:link href="/2011/02/10/redo-over-multiple-weeks/feed/" rel="self" type="application/rss+xml" />
	<link>http://dboptimizer.com/2011/02/10/redo-over-multiple-weeks/</link>
	<description>database performance, SQL tuning and data visualizatoin</description>
	<lastBuildDate>Tue, 20 Aug 2019 11:13:01 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.6</generator>
	<item>
		<title>By: DB Optimizer &#187; Tuning Blog Entries</title>
		<link>http://dboptimizer.com/2011/02/10/redo-over-multiple-weeks/#comment-696</link>
		<dc:creator>DB Optimizer &#187; Tuning Blog Entries</dc:creator>
		<pubDate>Thu, 20 Oct 2011 18:35:48 +0000</pubDate>
		<guid isPermaLink="false">http://dboptimizer.com/?p=573#comment-696</guid>
		<description><![CDATA[[...] Redo over weeks [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Redo over weeks [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: L.Ney</title>
		<link>http://dboptimizer.com/2011/02/10/redo-over-multiple-weeks/#comment-154</link>
		<dc:creator>L.Ney</dc:creator>
		<pubDate>Sun, 20 Mar 2011 02:57:03 +0000</pubDate>
		<guid isPermaLink="false">http://dboptimizer.com/?p=573#comment-154</guid>
		<description><![CDATA[Kyle,

You can easily put the query in perfsheet by Tanel. ;) 
 and get a nice graph.]]></description>
		<content:encoded><![CDATA[<p>Kyle,</p>
<p>You can easily put the query in perfsheet by Tanel. ;)<br />
 and get a nice graph.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark W. Farnham</title>
		<link>http://dboptimizer.com/2011/02/10/redo-over-multiple-weeks/#comment-137</link>
		<dc:creator>Mark W. Farnham</dc:creator>
		<pubDate>Sun, 27 Feb 2011 21:25:22 +0000</pubDate>
		<guid isPermaLink="false">http://dboptimizer.com/?p=573#comment-137</guid>
		<description><![CDATA[Would the graphic be more powerful, or just more succinct to some eyes?
I find it difficult to calculate things like least squares, confidence levels, standard deviation +1 and -1 bounds from graphics, while if you have the raw data that isn&#039;t a problem. Or did you much something different by ascii display than raw data? Those hinky asterisk stack charts tend to be less readable than raw data.
I would think the ideal calendar metric display chart would accept a calendar and clock granularity and have an api to chuck in the raw data points you have, which would be some datetime and a scalar and then interpolate, scale, and rate them with some rating under the various time ranges about the level of confidence. The graphic display enging, given a calendar and clock granularity should work for any arbitrary set of data points on a time line, not just redo. The calendar might include day of week orientation, but months and quarters might also be useful. In some shops handling week of fiscal month might be useful for analyzing load patterns. For example, some places use 4-4-5 patterns to get three months and 13 weeks per quarter, and to analyze them usefully you probably want to have the engine understand that the fourth week of the first two months corresponds to the fifth week of the third month. Sigh. And of course 365.25/7 is not exactly the same as 52*7, so things drift and about every 5.6 years you need an extra week. That doesn&#039;t screw up the week of month stuff, but you get a quarter with a whole extra week, so go figure.

Good luck,

mwf]]></description>
		<content:encoded><![CDATA[<p>Would the graphic be more powerful, or just more succinct to some eyes?<br />
I find it difficult to calculate things like least squares, confidence levels, standard deviation +1 and -1 bounds from graphics, while if you have the raw data that isn&#8217;t a problem. Or did you much something different by ascii display than raw data? Those hinky asterisk stack charts tend to be less readable than raw data.<br />
I would think the ideal calendar metric display chart would accept a calendar and clock granularity and have an api to chuck in the raw data points you have, which would be some datetime and a scalar and then interpolate, scale, and rate them with some rating under the various time ranges about the level of confidence. The graphic display enging, given a calendar and clock granularity should work for any arbitrary set of data points on a time line, not just redo. The calendar might include day of week orientation, but months and quarters might also be useful. In some shops handling week of fiscal month might be useful for analyzing load patterns. For example, some places use 4-4-5 patterns to get three months and 13 weeks per quarter, and to analyze them usefully you probably want to have the engine understand that the fourth week of the first two months corresponds to the fifth week of the third month. Sigh. And of course 365.25/7 is not exactly the same as 52*7, so things drift and about every 5.6 years you need an extra week. That doesn&#8217;t screw up the week of month stuff, but you get a quarter with a whole extra week, so go figure.</p>
<p>Good luck,</p>
<p>mwf</p>
]]></content:encoded>
	</item>
</channel>
</rss>
