<?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: Consistent Gets not Necessarily the Best Way to Look at Query Performance</title>
	<atom:link href="http://www.pythian.com/news/1171/consistent-gets-not-necessarily-best-way-to-look-at-query-performance/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pythian.com/news/1171/consistent-gets-not-necessarily-best-way-to-look-at-query-performance/</link>
	<description>News and views from Pythian DBAs</description>
	<lastBuildDate>Fri, 10 Feb 2012 13:01:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Maniek</title>
		<link>http://www.pythian.com/news/1171/consistent-gets-not-necessarily-best-way-to-look-at-query-performance/#comment-258754</link>
		<dc:creator>Maniek</dc:creator>
		<pubDate>Sat, 16 Aug 2008 16:19:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1171/consistent-gets-not-necessarily-best-way-to-look-at-query-performance#comment-258754</guid>
		<description>Excellent test of hash join performance ;)</description>
		<content:encoded><![CDATA[<p>Excellent test of hash join performance ;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jan</title>
		<link>http://www.pythian.com/news/1171/consistent-gets-not-necessarily-best-way-to-look-at-query-performance/#comment-257587</link>
		<dc:creator>Jan</dc:creator>
		<pubDate>Thu, 14 Aug 2008 11:07:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1171/consistent-gets-not-necessarily-best-way-to-look-at-query-performance#comment-257587</guid>
		<description>Number of rows matters!

I saw it several times, usually after applying SQL Profiles, that the LIO went down, but the execution time went up. I had to look at execution plans. Sometimes it was because of an increased number of rows in the execution plan, sometimes because of PIO increased (less frequent blocks were used hence they were not in a buffer very often).

My rule of thumb during SQL tuning: Filters must be applied first, joins are the second.</description>
		<content:encoded><![CDATA[<p>Number of rows matters!</p>
<p>I saw it several times, usually after applying SQL Profiles, that the LIO went down, but the execution time went up. I had to look at execution plans. Sometimes it was because of an increased number of rows in the execution plan, sometimes because of PIO increased (less frequent blocks were used hence they were not in a buffer very often).</p>
<p>My rule of thumb during SQL tuning: Filters must be applied first, joins are the second.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Narendra</title>
		<link>http://www.pythian.com/news/1171/consistent-gets-not-necessarily-best-way-to-look-at-query-performance/#comment-257522</link>
		<dc:creator>Narendra</dc:creator>
		<pubDate>Thu, 14 Aug 2008 08:28:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1171/consistent-gets-not-necessarily-best-way-to-look-at-query-performance#comment-257522</guid>
		<description>Hi,

I did not quite get your point.
Can you please elaborate how your example explains your point ?
I could see that you are comparing 2 different queries for consistent gets / response time. The only interesting observation here (for me) was though first query returned count of 1 and second query returned count of 1000000, in both cases, consistent gets were same. I guess that effectively means Oracle was able to access same number of blocks, irrespective of &quot;accessing&quot; a single row or &quot;accessing&quot; 1000000 rows.
It would be interesting to see TKProf to determine the WAIT events for both queries.</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I did not quite get your point.<br />
Can you please elaborate how your example explains your point ?<br />
I could see that you are comparing 2 different queries for consistent gets / response time. The only interesting observation here (for me) was though first query returned count of 1 and second query returned count of 1000000, in both cases, consistent gets were same. I guess that effectively means Oracle was able to access same number of blocks, irrespective of &#8220;accessing&#8221; a single row or &#8220;accessing&#8221; 1000000 rows.<br />
It would be interesting to see TKProf to determine the WAIT events for both queries.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

