text:
THE SQL Server Blog Spot on the Web
Ask anyone what the primary advantage of temporary tables over table variables is, and the chances are they will say that temporary tables support statistics and table variables do not. This is true, of course; even the indexes that enforce PRIMARY KEY and UNIQUE constraints on table variables do not have populated statistics associated with them, and it is not possible to manually create statistics or non-constraint indexes on table variables. Intuitively, then, any query that has alternative execution plans to choose from ought to benefit from using a temporary table rather than a table variable. This is also true, up to a point.
The most common use of temporary tables is in stored procedures, where they can be very useful as a way of simplifying a large query into smaller parts, giving the optimizer a better chance of finding good execution plans, providing statistical information about an intermediate result set, and probably making future maintenance of the procedure easier as well. In case it is not obvious, breaking a complex query into smaller steps using temporary tables makes life easier for the optimizer in several ways. Smaller queries tend to have a smaller number of possible execution plans, reducing the chances that the optimizer will miss a good one. Complex queries are also less likely to have good cardinality (row count) estimates and statistical information, since small errors tend to grow quickly as more and more operators appear in the plan.
This is a very important point that is not widely appreciated. The SQL Server query optimizer is only as good as the information it has to work with. If cardinality or statistical information is badly wrong at any point in the plan, the result will most likely be a poor execution plan selection from that point forward. It is not just a matter of creating and maintaining appropriate statistics on the base tables, either. The optimizer does use these as a starting point, but it also derives new statistics at every plan operator, and things can quickly conspire to make these (invisible) derived statistics hopelessly wrong. The only real sign that something is wrong (aside from poor performance, naturally) is that actual row counts vary widely from the optimizer's estimate. Sadly, SQL Server does not make it easy today to routinely collect and analyse differences between cardinality estimates and runtime row counts, though some small (but welcome) steps forward have been made in SQL Server 2012 with new row count information in the sys.dm_exec_query_stats view.
The benefits of using simplifying temporary tables where necessary are potentially better execution plans, now and in the future as data distribution changes and new execution plans are compiled. On the cost side of the ledger we have the extra effort needed to populate the temporary table, and maintain the statistics. In addition, we expect a higher number of recompilations for optimality reasons due to changes in statistics. In short, we have a trade-off between potential execution plan quality and maintenance/recompilation cost.
The problem, though, is that temporary tables do not work quite how (almost) everyone expects them to…
Imagine if temporary tables and table variables did not exist, and we had a complex query with cardinality-estimation difficulties that would be best addressed by breaking the query into parts. The example presented below is necessarily simplified, and uses the AdventureWorks sample database to make it accessible. It is not a query with insurmountable optimization problems by any means, but bear with me.
IF OBJECT_ID(N'dbo.Demo', N'P') IS NOT NULL
DROP PROCEDURE dbo.Demo;
CREATE PROCEDURE dbo.Demo
@StartsWith nvarchar(50)
OrderCount = COUNT_BIG(DISTINCT th.ReferenceOrderID)
FROM Production.Product AS p
JOIN Production.TransactionHistory AS th ON
th.ProductID = p.ProductID
p.Name LIKE @StartsWith + N'%'
This procedure returns a count of orders containing a part whose name starts with the specification passed in as a parameter. For example:
EXECUTE dbo.Demo @StartsWith = N'E';
The only real optimization issue in this simplified example is parameter-sniffing. The number of rows that match the LIKE predicate varies widely depending on the value of the parameter, which can impact execution plan selection. When the SELECT query is compiled or recompiled, SQL Server uses the actual value of the parameter at the time to estimate the number of rows qualified from the Product table. If the SELECT statement happens to compile or recompile with a parameter that matches very few rows, we get an execution plan like this (click to enlarge the graphic):
EXECUTE dbo.Demo @StartsWith = N'[0-9]';
This plan is cached and reused next time the procedure is called, perhaps with a parameter value that matches more rows than before, but not enough to cause a recompilation:
EXECUTE dbo.Demo @StartsWith = N'M';
This results in a large number of Key Lookups and a Sort that spills to tempdb physical disk (the warning triangle is new in SQL Server 2012). The memory grant for the sort was sized for the expected 370 rows, not the 22,527 that actually turned up. (If you are curious about the Constant Scan and Compute Scalar in these plans, see my previous post on dynamic seeks for details).
One way (certainly not the only way) to address this parameter-sniffing problem is to ask SQL Server to compile a fresh query plan for the SELECT statement on every execution, using the OPTION (RECOMPILE) query hint:
ALTER PROCEDURE dbo.Demo
Now we get plans optimized for the particular parameter value at runtime, and (in SQL Server 2008 SP1 CU5 or later) the added bonus that the runtime value of the parameter is embedded into the query so the dynamic seek is not required:
However, we are imagining that the example query is much more complex than shown, and we decide to break it into two parts. The first part will fetch qualified items from the Products table, and the second will join the results (with statistics) to the History table. Remember that temporary objects do not exist for this part of the discussion, so we have to use a permanent table:
-- Real table to hold intermediate result
CREATE TABLE dbo.Temp
ProductID integer NOT NULL,
Name nvarchar(50) COLLATE DATABASE_DEFAULT NOT NULL
-- First part of the 'complex' query
INSERT INTO dbo.Temp
(ProductID, Name)
p.Name LIKE @StartsWith + N'%';
-- Second part referencing the 'temp' table
FROM dbo.Temp AS t
th.ProductID = t.ProductID
-- Show the statistics for the Name column
DBCC SHOW_STATISTICS (Temp, Name) WITH STAT_HEADER, HISTOGRAM;
DROP TABLE dbo.Temp;
This procedure is not very practical as it stands, because the CREATE TABLE and DROP TABLE statements would make it impossible for more than one user to execute it at the same time. Nevertheless, it does show how most people expect things to work regarding statistics, temporary table lifetimes, and compilation:
EXECUTE dbo.Demo @StartsWith = N'A';
There are three matching Product records, shown below together with the SHOW_STATISTICS output:
Nothing too surprising in the execution plans: the table INSERT is a trivial plan (no choices for the optimizer to make), and the SELECT query has cardinality estimates that are very close to the actual numbers encountered. The warning triangle on the SELECT (again, new for SQL Server 2012) is just suggesting an index for the History table, which we won't be adding on this occasion.
While the procedure was executing, a Profiler trace captured the following compilation and statistics activity:
The table is created, and since this is the first time the procedure has been run, the INSERT and SELECT statements both incur a deferred compilation. As part of the SELECT compilation, new statistics are created on the Name and ProductID columns of the new table, the DBCC SHOW_STATISTICS command executes, and finally the table is dropped. Now we execute the procedure again but for products that start with 'E' rather than 'A' as above:
This time there are nine matching records, though the statistics-gathering algorithms compress the information into the five histogram steps shown. The execution plan is below (trivial INSERT plan not repeated):
Again, the cardinality estimates are extremely good, and the optimizer selected a nested loops plus key-lookup plan based on costs computed according with the smaller number of expected rows. The trace captured the following:
The only change is that this time recompilation is triggered because the cached INSERT and SELECT plans reference a table that no longer exists, leading to a 'schema changed' recompilation. The crucial observations here are that the table is recreated and new statistics are gathered on every execution. This is the way most people expect tables, statistics, and compilations to behave inside stored procedures, so don't worry if there's nothing too surprising so far.
The previous example is not terribly practical. It is possible to conjure up schemes where ordinary tables can serve the purpose effectively, but as it stands, the procedure would likely cause runtime errors if more than one user or process attempted to execute it concurrently. In addition, ordinary tables do not benefit from engine optimizations that only apply to genuine temporary tables, so they tend to be less efficient, even if created in tempdb. We now return to the real world (where temporary tables do exist) and modify the procedure to use a temporary table instead of a permanent table:
CREATE TABLE #Temp
ProductID integer NOT NULL,
INSERT INTO #Temp
FROM #Temp AS t
DBCC SHOW_STATISTICS (N'tempdb..#Temp', Name) WITH STAT_HEADER, HISTOGRAM;
DROP TABLE #Temp;
Executing this procedure with an 'E' parameter produces exactly the same output as when the permanent table was used. Same execution plan, same statistics, same Profiler output, everything:
Now we will execute the procedure with a parameter value of 'T', which has 65 matching records in the Product table. This is the output (only the first nine of the 65 matching names are shown in the first result set):
The results are as expected (products that begin with 'T') but the SHOW_STATISTICS output displays 'E' statistics from the previous execution!
The execution plan has serious cardinality estimation errors. It has the same nested loops and key-lookup shape and estimated row counts as the 'E' execution, instead of being optimized for the 'T' data. This causes slow performance and a sort that spills data to physical tempdb disk.
The Profiler output explains why: no recompilations occurred, and no statistics were created. In fact, with the AdventureWorks database, there is no way to persist a different execution plan or update the statistics for this procedure without changing it (more on that later). Even executing with [A-Z] as the parameter reuses the plan optimized for the 'E' value:
EXECUTE dbo.Demo @StartsWith = N'[A-Z]';
The key lookup is now executed 113,443 times, and the sort has to perform a multi-pass spill to tempdb (previously only a single pass spill was required). Executing the procedure with the WITH RECOMPILE option will produce better plans, at the cost of recompiling the whole procedure, and the resulting plans will not be cached for reuse. In general, recompiling the whole procedure every time could be bad since many procedures have many more statements to recompile than just a single INSERT and SELECT. Although we have not yet identified a cause for the behaviour we are seeing, perhaps the answer lies in adding a RECOMPILE query hint to the SELECT statement as we did earlier for the parameter-sniffing example?
Thinking that the cause might be a new form of the parameter-sniffing problem, we now modify the procedure to add the RECOMPILE query hint to just the SELECT statement. This avoids recompiling the whole procedure on each call as EXECUTE … WITH RECOMPILE would do, and will hopefully solve our optimization problems:
Unsurprisingly, clearing the plan cache and executing with a parameter value of 'E' produces the exact same nested loops and key lookup plan as previously shown (and the same statistics and Profiler events too).
This is fine because it is the optimal plan for this value. The test for OPTION (RECOMPILE) comes when we try a second execution with the 65-row 'T' value:
EXECUTE dbo.Demo @StartsWith = N'T';
The execution plan has a different shape now, with the optimizer correctly preferring a hash join over the nested loops plus key lookup. The estimated cardinality is correct for the temporary table (65 rows versus 9 previously seen for 'E'), but it is badly wrong for the hash join (811 rows expected, 12,273 actual) and the distinct sort, which has to perform a single-pass spill to tempdb disk. The query output shows the reason for the inaccuracy:
The results are correct of course (65 products starting with 'T') but the statistics are again still reflecting the parameter value 'E'. The RECOMPILE query hint allows the optimizer to see the true cardinality of the temporary table (65 rows) but the 100% wrong statistics on the ProductID column used to estimate the cardinality of the join to the History table result in a mess of a plan from that point forward. (Note that statistics on the Name column are also considered interesting by the optimizer for this query due to the GROUP BY clause. The SHOW_STATISTICS output above shows the Name statistics because it more immediately shows that 'E' values are stored; the ProductID statistics are integers, and much harder for the reader to correlate with the parameter).
The Profiler output above confirms the recompilation due to the query hint, and that no statistics were created or updated. An interesting thing occurs if we execute the procedure four more times with the same 'T' parameter (a total of five times with 'T'):
The first three of those executions are exactly as before, but the fourth one suddenly produces this different execution plan:
The estimates are now well within the boundaries of expected accuracy, and the sort now receives enough workspace memory to avoid spilling rows to tempdb.
The statistics have been updated, and now show 65 rows that start with 'T' sampled (compressed into 49 histogram steps). This is confirmed by the trace output:
Notice the StatMan and AutoStats entries showing the ProductID and Name statistics being updated. Unfortunately, executing the procedure again with a new parameter value takes us back to inaccurate cardinality estimates again. The execution plans for this procedure aren't always a disaster, but this is pure luck – poor estimates are poor estimates, whether the query plan happens to perform acceptably or not. We really need to get to the root cause here. Perhaps OPTION (RECOMPILE) was not the way to go, and we should try a manual statistics update instead of relying on automatic statistics updates…?
We know we want to add an UPDATE STATISTICS command to our stored procedure instead of the OPTION (RECOMPILE) … but where to put the new statement exactly? The statistics we want to update are created during compilation or recompilation of the SELECT statement, suggesting the UPDATE STATISTICS should come after the SELECT; but then how could it possibly affect the preceding SELECT plan? It seems the only sensible place to put it is before the SELECT, however counter-intuitive it might seem.
UPDATE STATISTICS #Temp;
Following the same pattern as before, we clear the plan cache (though this isn't strictly necessary since the ALTER PROCEDURE evicts plans from the cache anyway) then execute with 'E' and 'T' parameters as before.
The results for the 'E' execution are the same as always, so here are just the results for the 'T' execution:
The above output looks very promising: correct results and the statistics have been updated to reflect the 'T' parameter.
The trace output shows the statistics updates too…but no recompilation.
The execution plan is a disaster. The estimated number of rows in the temporary table is 9 (the number of rows the 'E' execution produced not the 65 actually present), and everything is wrong from that point forward, including the sort spilling to tempdb again. The UPDATE STATISTICS command did its job, but the cached query plan did not recompile – though we might expect that it should, right?
As with the first temporary table example (no RECOMPILE or UPDATE STATISTICS) this plan is stuck in cache, given the AdventureWorks database. No parameter value will cause a recompilation, and every subsequent execution will use the 'E' plan. This is very reminiscent of the parameter-sniffing problem we encountered earlier, though the SELECT query in question has no direct parameter value to be sniffed! In a final effort to produce reliable plans, our last attempt will be to combine both RECOMPILE and UPDATE STATISTICS…
Our stored procedure now includes an UPDATE STATISTICS before the SELECT, and an OPTION (RECOMPILE) query hint on the SELECT itself:
Our usual test executions:
The first 'E' execution performs as it always has: correct statistics and an optimal query plan. The results for 'T' are:
The output is correct, and so are the statistics: 65 rows sampled, stored in 49 histogram steps.
Success! All estimates are very good, the sort is performed in memory, and the query executes quickly. Further experimentation with other parameter values shows that new statistics are always generated, and the SELECT query plan always recompiles to use those statistics. If you are concerned by the small discrepancy after the hash join (estimate 10,449 rows; actual 12,273) don't be. Cardinality estimation is a tough problem – try using the statistics histograms yourself to predict how the ProductID values in the temporary table (65 rows in 49 steps, remember) will join to the histogram on the same column for the much larger History table. You'll find the data there even more compressed, so the task of matching values to values using RANGE_ROWS, EQ_ROWS and so on is really not an easy one at all.
The final option we are going to look at is using a table variable instead of a temporary table:
DECLARE @Temp AS TABLE
Name nvarchar(50) NOT NULL
INSERT INTO @Temp
FROM @Temp AS t
There are a couple of small changes to the procedure here. The COLLATE clause is not necessary in the definition of the Name column, since the default for table variables is the collation of the host database anyway (the default for temporary tables is the collation of tempdb). There is no need (or option) to drop the table at the end of the procedure; table variables simply go out of scope. There is no SHOW_STATISTICS statement either, since table variables do not support statistics (even on constraint-supporting indexes). The first execution with a parameter value of 'E' produces this execution plan and trace output:
The OPTION (RECOMPILE) on the SELECT statement ensures that the cardinality estimate for the table variable is exactly right, but the lack of statistics means the optimizer resorts to guesses after that point. The guessed estimates turn out to be higher than the actual number of rows, so no performance problems result, although the sort is allocated more memory than it needs. The trace output is a bit smaller than before, since no statistics are created.
The second test is with a parameter value of 'T':
Again, the number of rows in the table variable is exactly right due to the RECOMPILE, and the later guesswork also turns out to work quite well. As you can see, the overall shape of the plan is quite different for this parameter value (hash joins versus nested loops for example). There is one cardinality estimation problem at the middle hash operator, but whether it causes performance problems or not depends on your version of SQL Server. To make the issue clearer, we will perform one final test, a parameter value of '[A-Z]', qualifying all 504 products:
Once more, the table variable cardinality is exactly right (504 rows). Both inputs to the hash join look exactly right, and the guessed output from that join is also very close to the actual. The lack of statistical information makes itself felt at the middle hash operator though; the optimizer has no idea how many distinct values there might be of the combination (Name, OrderID), so it guesses at 2,825. This is very much smaller than the 113,338 actual, and the hash table spills out to tempdb physical disk as a result.
The table variable approach happens to produce reasonable plans in some cases, based on the sniffed table cardinality provided by OPTION (RECOMPILE) but the lack of statistics leads to wild guesses and potential performance issues deeper in the tree. It's interesting that one of the main perceived benefits of table variables – fewer recompilations – has to be abandoned in order to produce semi-reasonable plans. This follows hard on the heels of our seeing the main benefit of temporary tables – statistics – being 100% wrong earlier!
The last thing I want to mention about table variables is that for all their limitations, they do something else temporary tables cannot: a join from a table variable is estimated for the average case summed over all rows. This is similar to hinting OPTIMIZE FOR UNKNOWN for a temporary table query with a parameter, but the average-case estimation occurs for all joined rows, not just one predicate, and of course there is no parameter variable in a join for OPTIMIZE FOR UNKNOWN to work on anyway.
At this point, you should have some questions. Why does the temporary table behave so differently from the permanent table? Do you really have to UPDATE STATISTICS before they are created, and add OPTION (RECOMPILE) when you use temporary tables this way? Why does the RECOMPILE query hint only produce the desired effect with temporary tables every so often? Part of the answer to these questions lies with the caching of temporary tables first introduced to SQL Server in the 2005 version.
I will talk about this in much more detail in my next post, but the key point is that CREATE TABLE and DROP TABLE do not create and drop temporary tables in a stored procedure, if the temporary object can be cached. The temporary object is renamed to an internal form when DROP TABLE is executed, and renamed back to the same user-visible name when CREATE TABLE is encountered on the next execution. In addition, any statistics that were auto-created on the temporary table are also cached. This means that statistics from a previous execution remain when the procedure is next called. The following code demonstrates the object id of a temporary table remaining the same between executions (there will be a more comprehensive demonstration in my next post):
CREATE TABLE #Temp (col1 int NULL);
SELECT ObjectID = OBJECT_ID(N'tempdb..#Temp');
EXECUTE dbo.Demo;
This is very different from the case where we used a permanent table. With a permanent table, CREATE and DROP definitely do create and drop a table on each execution of the procedure. The table is new each time, new statistics are created, and new plans are compiled on each execution. The permanent table behaviour is probably more intuitive than the apparently strange behaviour of cached temporary tables, but it does allow temporary tables an opportunity to cache plans and temporary objects for reuse, which is not possible when using a permanent table in the way we did.
Most of you will be familiar with the concept of recompilation thresholds, as described in the Plan Caching in SQL Server White Paper. Briefly though, cached query plans include a Recompilation Threshold (RT) for statistics considered interesting by the optimizer while compiling the plan. The query plan also records the cardinality of tables and indexed views referenced by the plan, at the time the plan is compiled. (I demonstrated how to determine which statistics are considered 'interesting' by the optimizer during compilation in a previous post).
Generally, if the column modification counter (colmodctr) for interesting statistics change by RT or more, the query recompiles. Similarly, if the table cardinality has changed by RT or more compared with the value stored at the time the cached plan was created, the query plan also recompiles. The value of RT depends on the type of table (permanent or temporary) and the number of rows (n) in the table or indexed view at the time of compilation. The following summary of RT values is taken from the White Paper:
There is another condition not listed above. If the table is empty at compilation time, RT is set to 1.
I say "generally" above because although queries referencing permanent tables recompile when interesting statistics modification counters change by RT or more, this is not the case for cached temporary tables in stored procedures, which only recompile when table cardinality changes by RT or more, unless OPTION (RECOMPILE) is used, when statistics counters come back into play. If this sounds confusing, that's because it is. It may be a bug, but on the other hand, it does seem reasonable that a cached temporary table should not cause a recompilation simply because the procedure is called a number of times with the same parameter, with the number of modifications accumulating on each call to eventually pass RT. In that specific case, we would probably prefer no recompilations. I will probably file a Connect item to get the situation with statistics modification counters and temporary tables clarified. Update: the Connect item can be found here.
In our experiments, this explains why the vanilla temporary table procedure (with no RECOMPILE or UPDATE STATISTICS) stuck with the same plan, whereas adding RECOMPILE meant the plan would occasionally recompile (when accumulated changes passed RT). The vanilla procedure was initially called with a parameter value of 'E', which compiled a SELECT execution plan when 9 rows were in the temporary table. Following the rules above for n=9, this means RT was set to 500, so the plan would recompile when n reached 9 + 500 = 509. The AdventureWorks Product table only contains 504 rows, so that target could not be reached, and the plan never recompiled.
When OPTION (RECOMPILE) was added, the modification counters did accumulate to eventually pass RT. The first execution was the same, with the 'E' parameter value resulting in 9 rows in the temporary table at compilation time, with RT = 509 as before. We then ran the procedure a total of five times with a parameter value of 'T'. There happen to be 65 product names that start with 'T', so five executions resulted in 5 * 65 = 325 changes. This does not reach the target of 509, but there is a second factor in play here. Although the temporary table is not dropped at the end of the procedure (just renamed), it is implicitly truncated (whether an explicit DROP TABLE is included in the procedure or not). This implicit truncation removes 65 rows on each execution, and this action adds to the modification counters.
On each 'T' execution then, 65 modifications are counted when the rows are added to the temporary table, and 65 more when the table is silently cleared at the end of the procedure. In total, the first four 'T' executions result in 65 * 2 * 4 = 520 modifications, which is enough to pass the 509 target. That in itself is not enough to cause a recompilation though, because the RT test is performed as each query is retrieved from the plan cache for execution, and the final 65-row truncation happens at the end of the procedure, after the SELECT has already completed. On the next execution, whatever parameter is passed in, a recompilation will occur at the SELECT query. The OPTION (RECOMPILE) version of the procedure is reproduced below:
Now run the tests as described above:
-- 9 rows, RT = 509
-- 65 rows, 4 times = 260
-- Plus truncation modifications = 520
-- No rows, but plan still recompiled
EXECUTE dbo.Demo @StartsWith = N'5';
There are no products that start with '5', but the 520 modifications already performed cause a recompilation anyway:
No results, and NULL statistics created! Luckily, the new RT value after this compilation is 1, so just one row is needed to produce a new plan. This is demonstrated by calling the same procedure again with a 'K' parameter value (just one product name starts with 'K'):
EXECUTE dbo.Demo @StartsWith = N'K';
After this compilation, the new RT is 1 + 6 = 7, which can be confirmed by executing the procedure with a parameter value of 'P' (there are exactly seven Product rows where the name starts with 'P'). And so on.
I should mention though, that it is just the carry-over of accumulated modifications that requires OPTION (RECOMPILE). Without this query hint, modifications are still accumulated within a single execution of the procedure (and may result in recompilation local to that single execution) but any accumulation is not carried over to the next procedure execution.
So far we have explained how the vanilla and OPTION (RECOMPILE) procedures produce the observed behaviour. The next configuration to examine is where OPTION (RECOMPILE) is not specified, but an UPDATE STATISTICS statement appears before the problematic SELECT query. It should now be apparent that the placing of the UPDATE STATISTICS statement works because auto-created statistics from a previous execution are cached, and available for update by the next execution. The one remaining question is why the updated statistics do not cause a recompilation in our example – remember we saw correct statistics, but the execution plan was not rebuilt to reflect the new information. This is either a bug, or another example of different behaviour for cached temporary tables. In any case, the observed behaviour does not match that described in the White Paper (the same diagram appears in the SQL Server Internals books from Microsoft Press):
Whether this is a bug or undocumented designed behaviour (and it is the same on all versions of SQL Server from 2005 to 2012 inclusive) the effect is clear: UPDATE STATISTICS on a cached temporary table in a stored procedure is not enough on its own to force recompilation of a query plan. A recompilation may still occur for other reasons, for example if the cardinality of the table has changed by RT or more compared with the cardinality value stored with the cached plan. This cannot happen with our UPDATE-STATISTICS-only test procedure as shown earlier, since the first execution with the 'E' parameter value adds 9 rows to the temporary table, setting RT to 509, and the AdventureWorks Product table only has 504 rows in total as mentioned earlier.
For the moment, at least, we may need to specify OPTION (RECOMPILE) as well as UPDATE STATISTICS if we want to be sure of a plan specific to the contents of a cached temporary table on each execution.
Temporary tables in stored procedures have a number of characteristics that may seem unexpected:
It is possible that one or more of these behaviours is unintentional, but they have been this way for a very long time, and so are very unlikely to be changed. Temporary tables behave quite similarly (aside from the UPDATE STATISTICS behaviour) to an in-procedure reference to a permanent table that was created outside the procedure. It may be that some of the features of temporary tables shown in this post have their roots in a design that sought to mimic permanent table behaviours using non-sharable local temporary tables. On the other hand, it might be simply that the current arrangement provides the best chances for caching and reuse, and we are expected to take action where we suspect reusing the cached plan, temporary object, and/or statistics may not be optimal. Who knows.
How likely you are to be affected by the issues illustrated in this post depends on usage. A temporary table that contains wildly differing numbers of rows on every execution is unlikely to be affected. If the recompilation threshold is passed, chances are you will get good statistics and any cached plan with recompile without intervention. For a plan cached when the temporary table contained 10,000 rows the default threshold is 500 + 0.2 * 10,000 = 2,500 rows. This means the next execution with more than 12,500 rows or fewer than 7,500 rows will pass the threshold test. The formula to compute RT values when trace flag 2371 is enabled is unknown to me.
In principle, in later versions of SQL Server, we can look in the plan cache to check the cardinality of a temporary table and deduce the RT from there, but this is not convenient to do routinely. In practice, RT moves around a fair bit, so it can be hard to know how often a procedure might use stale cached statistics or a sub-optimal cached plan. Avoiding temporary table caching removes the risk of stale statistics, but a cached plan may still be used unless the RECOMPILE query hint is used. Avoiding temporary table caching will also tend to increase contention on tempdb, and can be difficult to enforce in practice.
Procedures that routinely store relatively small result sets and use cached temporary tables are probably most at risk. This is quite a common scenario: temporary tables are often used for smaller sets (writing away large temporary tables is more difficult to justify). One scenario that springs to mind is where a delimited string is passed as a parameter, split to a cached temporary table, which is then used to drive a more complex query. The plan for the complex query may be very sensitive to the cardinality and statistical distribution of values in the temporary table, so 100% wrong cached statistics and/or inappropriate plan reuse may be a problem. I'm sure there are many other scenarios.
It is quite ironic that the poor temporary table execution plans shown in this post are caused by the thing that is perceived to be their greatest strength: the availability of distribution statistics. Some care is needed when choosing between table variables, temporary tables or another technique; the right choice in any particular circumstance will depend on many factors, only a few of which have been discussed today. Whichever option you choose, be sure to understand the choice you have made and the trade-offs that result.
There are also times where the best-performing solution will be to carefully craft one huge query, perhaps using hints and/or specific syntax tricks. This approach is perfectly valid but requires careful thought as future maintenance may be harder, and data changes over time may mean the carefully-designed manual execution plan gradually (or suddenly) becomes sub-optimal. My general preference is still for simpler relational queries and, where necessary, for temporary tables over table variables as a starting point, but the details do indeed depend on the details. If you happen to be attending the PASS Summit 2012, I will be speaking more about these sorts of things in my half day and regular sessions.
I hope you enjoyed this post, the next one will cover details of temporary table caching that I did not have space for today. I would like to thank Dave Ballantyne (blog | twitter) for his help with today's post.
Working with tempdb in SQL Server 2005 – TechNet Library
Plan Caching in SQL Server 2008 – MSDN Library
© 2012 Paul White
email: email@example.com
twitter: @SQL_Kiwi
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using
This is a very interesting post. I asked my team to read it. Thank you for taking time to write it up.
If you create temporary tables implicitly, via SELECT INTO, do you observe the same behavior?
Good post Paul!
Very interesting note about colmodctr and option(recompile), as I understood it is assumed to be empirical and not documented anywhere? If so, you should definitly file a connect item, I'll vote.
Because it seems to be logical that option(recompile) doesn't affects stats (or we would have a lot of update stats when using option recompile for other purpose), but it is not logical, that it starts accumulating mods and suddunly leads to update stats. It may lead to a kind of "mystery behaviour" when debugging. So thank you for pointing that!
Also I consider that explicit update stats should cause a recompilation in any way (I even tried explicitly create stats - no effect, the only issue to deal without recompile and updatestats is to put "alter table #temp rebuild;" - command, than it is effect, but that is realy nasty, especially for big tables, but hopefully may be not so harmfull for small...)
Hi Alex,
Thanks for that, I appreciate it. Yes, the same behaviour applies to temporary tables created with SELECT...INTO, as the modified version of the test procedure below demonstrates.
ALTER PROCEDURE dbo.Demo @StartsWith nvarchar(50)ASBEGIN SET NOCOUNT ON;
SELECT p.ProductID, p.Name INTO #Temp FROM Production.Product AS p WHERE p.Name LIKE @StartsWith + N'%';
SELECT t.Name, OrderCount = COUNT_BIG(DISTINCT th.ReferenceOrderID) FROM #Temp AS t JOIN Production.TransactionHistory AS th ON th.ProductID = t.ProductID GROUP BY t.Name;
DBCC SHOW_STATISTICS (N'tempdb..#Temp', Name) WITH STAT_HEADER, HISTOGRAM;
DROP TABLE #Temp;
END;GODBCC FREEPROCCACHE;EXECUTE dbo.Demo @StartsWith = N'E';EXECUTE dbo.Demo @StartsWith = N'T';
That said, tables created this way tend to have at least one index created explicitly after the SELECT...INTO, which will prevent temporary table caching (see the White Paper for details). That action will prevent statistics being cached across executions, but does not the solve the other issues shown in the main post.
Hi Dima (SomewhereSomehow),
Thanks. I will try to put a Connect item together soon, and update the post above with the details.
An explicit CREATE STATISTICS counts as DDL on the temporary table, which prevents temporary table caching (and the caching of statistics that does with it), but as I mentioned to Alex Kuznetsov above, that does not solve the other issues (and it means we don't get the benefit of temporary object caching either, of course). Rebuilding the table works, naturally, but it is, as you say, not a happy solution!
I'm glad you enjoyed this post; there will be more details on the caching mechanism in the next one.
I have now added a Connect item:
Great post, as always!
I knew about SQL Server caching temporary tables, but I would never imagine that statistics created by AutoStats on those tables were cached too. More intriguing to me is the fact that there is no recompilation of the cached plan referencing the cached temp table, after manually updating the cached statists that were found interesting during compilation. I am also surprised about the way OPTION (RECOMPILE) carried column modifications between procedure calls.
I already added my voted.
Thanks for sharing your findings with us.
Hi AMB,
Do you realize you just summarized in 30 words what it took me 6,600 words to say? LOL! Seriously, thanks for that - it's good to hear that the points I was trying to make were received as intended, and that you found it as surprising as I did. Thanks also for the vote.
Wow - I think this really explains some stuff that I used to fight with in "search" procedures using temp tables.
Thanks for another fantastic read - that I will need to read one more time to digest.
SQL Server 2005 onward caches temporary tables and table variables referenced in stored procedures for
Regarding Recompile Thresholds I've encountered a case where increasing table cardinality from 10 to 1,000,000 still doesn't seem to cause an optimality based recompile.
Great Post Paul!
I usually get distracted in between when there is a big post and takes me longer than usual to read through the whole post, but in this one I was hooked and read it in one go and couldn't believe what I used to beleive about the Temp Tables.
Would the bevaiour of the temp table be same if there lot of execution happens simultaneously on the same stored procedure in highly busy OLTP server (around 20,000 executions/min of a stored procedure). Would it still use the same cached temp table or multiple copies of the temp table, how the colmodctr would behave if there are multiple temp tables are created?
Sat Pal
Hi Martin,
Yes, on the face of it, I would expect that to recompile due to the change in cardinality of #T from 10 when the plan was cached to 990000 for the second execution.
I notice that it does behave as I would expect so long as there are no leading-column statistics associated with an index on column 'n' of #T. There are two things I tried: (1) commenting out the PRIMARY KEY, so #T becomes a heap and *auto-statistics* are created for column 'n'; (2) changing the PRIMARY KEY to (s, n) - a clustered table without leading-column index statistics for 'n'. (The odd behaviour still reproduces if the PRIMARY KEY is NONCLUSTERED on 'n'.)
It seems statistics associated with a constraint on a cached temp table might have a different behaviour from auto-statistics. I'm about to leave for a weekend away, so I won't have chance to dig into this further for a few days.
There is no shortage of odd behaviour in this area, and I am sure I didn't cover it all even in this very long post. One thing to try: run your repro again, but after EXEC t2 10; display an estimated plan for EXEC T2 1000000; just before running EXEC T2 1000000; 'for real'.
The table cardinality of #T in the estimated plan is zero. The cached temporary table is not reused. A *new* temporary table briefly exists, creates *new* statistics and is then dropped. The 'real' execution of EXEC T2 1000000; that follows recompiles with a reported reason of 'Option (recompile) requested' - even though we didn't.
Honestly one can go gradually mad trying to make sense of all this.
Hi Sat Pal,
I was a bit worried about the length of this one, so thanks for the feedback on that.
I think I answer your questions about simultaneous executions in my follow-up post (at http://bit.ly/TempCaching).
Strange behaviour indeed that requesting an estimated plan should affect things like that!
I've also found that the modification counter doesn't always seem to get updated.
Starting with an empty procedure cache whether or not the rcmodified column in sys.sysrscols is updated after executing the procedure seems to depend upon the value passed to the stored procedure and hence temp table size.
For me anything between 1 to 277843 (temp table size = 275065 rows) leaves rcmodified at 0. Whereas from "EXEC T2 277843;" upwards (temp table size = 275066 rows) updates this value.
Great post Paul, thank you very much for taking the time!
A very, very interesting post! Thank-you for taking the time out and writing it, Paul! I will be reading it again tomorrow, ask the team to read it and then spend a couple of hours during week-ends trying to digest everything. Thank-you very much!
Hi Paul,
Excellent post!
Some time back I had my encounter with parameter sniffing. All that I could find online was just a few posts - providing just high end theoretical information.
Compared to that, your post is entirely different in content.. good job.
Thanks to my friend Shyam Viking for bringing my attention to this post.
I have a simple question given the complexity of the subject matter.
Would it make sense in some cases to dynamically (programatically) change the name of the temporary tables everytime the stored procedure is run in order to be sure you have accurate statistics.
Connecting via the DAC to see sys.sysrscols (or sys.sysrowsetcolumns in 2005) I have noticed that issuing a CHECKPOINT seems to cause the in-memory counters to be flushed to persistent storage, so you might want to try that. With larger values, you might be seeing flushing based on number of changes (this is just speculation on my part) without needing CHECKPOINT.
That said, in my simplified tests I found it more convenient to query rowmodctr from sysindexes on a regular connection. So long as one bears in mind the differences between colmodctr and rowmodctr, this can still be an effective technique.
Hi John,
Good question. You certainly could use dynamic SQL to create temporary tables each time, and this would prevent caching as I describe in the follow-up post to this one at http://bit.ly/TempCaching
I can't think of any cases where this sort of scheme would be worth the effort though. All it achieves is to prevent temporary table caching, so you lose the benefit of that, and statistics creation and deferred compiles will happen on each execution of the new stored procedure anyway. It seems to me that there are better way to achieve the same effect (at least ways that would be easier to maintain in future).
My own preference at this point in time, is to use UPDATE STATISTICS and OPTION (RECOMPILE) wherever I think temporary table and statistics caching might cause me a problem.
Just wanted to say that this is a fantastic post, Paul. Well researched and well written!
Are those Plan Explorer screen shots, btw? Just curious...
Thanks again,
Hi Kevin,
Thanks! Yes, the screenshots are from SQL Sentry's Plan Explorer; I find its display style convenient for blog posts.
Nice post Paul - will be linking to it in my class deck on tempdb and temp table abuse.
Awesome! Thanks Paul.
Thanks a ton Paul...
Wonderful article..
Thanka a billion Paul.
wonderful and helpful article. thanks @Paul White
Wonderful article ! Thanks Paul
Very nice post. I can think of several stored procedures I have to look at now and optimize. Thank you!
Very nice post.
Excellent post, really useful. But I just checked your Connect bug submission - Microsoft have just closed it in thye past week as "Won't Fix". Apparently it's too obscure to invest any effort in.
Hi Gary,
Thanks - and yes, I noticed *sigh* :)
Excellent Post,its very useful.
I have one question-
I want to add new row in temporary table as like we add new row in data table in C#,Is it possible?
Paul, this is fantastic stuff, I read this a couple of months ago and have been applying it to some of our SPs, and I believe it is helping.
What we had are SPs that, a few times a day, would just seem to lose their minds and run 100x slower. The same parameters rerun would run much faster. I'm pretty sure this is "The Paul White Bug", that's how I'm labelling it in my code! Applying these update stats to newly created #temps, seems to stabilize the behavior. Sometimes I get ambitious and wait until I repopulate the SPs before doing the update stats, tradeoff about cost and accuracy.
As for Microsoft closing it in Connect - I've had very poor experience with Connect for a long, long time, not sure what else to say about it.
I think we interacted a couple of times on the MSDN forums, so hello again :)
I'm so glad to hear you have found this entry useful, thanks very much for letting me know of your experiences.
... I meant repopulate the #temps of course.
Sure, I often think out loud on the forums, just posting it solves the problem half the time, you know how it is! :)
Appreciate all your work, whereever it goes!
Hi paul,
I am(yr FAN) a regular reader of your blog and a first time commenting.
your findings and dedication to make the community stronger is phenomenal,
could you please give me some link or examples to back yhis statement
"In addition, ordinary tables do not benefit from engine optimizations that only apply to genuine temporary tables, so they tend to be less efficient, even if created in tempdb."
will be helpfull.
Many of the differences can be found in the tempdb White Paper at http://technet.microsoft.com/library/Cc966545. You might also like to read the Storage Engine blog entries on tempdb at http://blogs.msdn.com/b/sqlserverstorageengine/archive/tags/tempdb. Finally, there is the three-hour Bob Ward video from PASS Summit at http://www.youtube.com/watch?v=SvseGMobe2w
Thanks for the fantastic post!
Is the "DROP TABLE" necessary to produce this behavior? Or will the implicit drop (when the connection on which the procedure is executed closes) also result in caching of the temp table and its auto-created statistics?
Hi Kenny,
No, the DROP TABLE isn't required - the implicit drop has the same effect.
Great post, thank you!
How about using "WITH RECOMPILE" on the SP level? I noticed in my tests that it did force the creation of a correct plan and statistics every time.
Yes, though as I mentioned in the main text:
"Executing the procedure with the WITH RECOMPILE option will produce better plans, at the cost of recompiling the whole procedure, and the resulting plans will not be cached for reuse. In general, recompiling the whole procedure every time could be bad since many procedures have many more statements to recompile than just a single INSERT and SELECT."
Whoops, missed that, thanks.
But what's the explanation for the SP-level RECOMPILE working differently than the statement-level RECOMPILE? I mean, even if we add OPTION(RECOMPILE) to every single statement in the SP, it would still behave differently.
My guess is that the SP-level RECOMPILE disables the temp table caching.
When RECOMPILE is specified on the procedure, there is no top-level plan cached for the statistics to be associated with.
Well that's better. Interesting!
Just wanted to say thanks for the write up, helped me tonnes.
Really disappointed to see Microsoft ignoring your connect item simply because the issue has been there for so long. Some times it takes "us" (the public) this long to realise the crazy s**t that their software is doing!
Hey Paul:
Thanks so much for this. I've been racking my head against a wall trying to figure out why estimated and actual rows are so vastly different in my environment I inherited where the use of #temptables inside stored procedures is insanely abused.
Have you submitted this as a question of the day to SQL Server Central? If you haven't, would you give me permission to do so and I will give you credit, and link to your post?
Hi Lara,
Glad you found it helpful. I haven't written an SSC QotD for this - and you don't need my permission to do so yourself :) Have fun.
Thanks for the permission Paul. The QotD is up today and getting lots of good feedback.
Happy to report I answered correctly and earned 2 points :)
An informative and incredible write up. Great job!
hai paul,
is there any impact if i create many #temp table in one store procedure?
Thanks Paul, still need to diggest all the information on this blog post and the following one about temporary tables and caching but so far it has been amazing. I'm pretty sure the perf problems we are having (search sp's with lot of temporal tables) have lot to do with all you explain here. Thanks a lot, for real...
Great post Paul! I couldn't agree more regarding breaking out complex queries into intermediate temp tables. Some people talk about the tempdb usage, but I've yet to find a complex query that didn't create a worktable. Better to do it explicitly I think. Also you have to know where to break the query up.
It's also nice knowing simple plans will survive multiple upgrades of the SQL Engine.
Hi Derek,
Thanks for the comment, you make some great points.
Indeed, the skill is in knowing *when* and *where* to simplify a query using a temporary table. I occasionally come across systems where someone has just gone nuts with the idea, leading to tempdb contention or other issues, but for the most part I find even experienced SQLers underuse this idea.
I really enjoy this post. Thanks so much Paul.
Very well written post Paul, thanks for going into such detail. You have just helped me reduce the execution time on my stored procedure from 44secs to 1sec by using a temporary table, amazing difference. My SQL reports are now actually usable! Many thanks.
Great article...Would creating an clustered index on the temp table help in this situation ?
great article....
So would a temporary table that stores the exact same count of rows as a parameter from the app potentially be impacted, or only if the population count goes up and down each time?
I have an app that pass through a table parameter with a fixed 500 count rows. Later this result is joined to by other tables. If the count of results is the same in the temp table, but the resulting matches in the other tables could vary with high or low counts coming back, would the recompile impact this significantly? I don't think I'd need to update statistics in this case, would I?
If the distribution of values within the similar/same number of rows changes, and that change means the execution plan ought to be different, then yes you could see an adverse impact. For such a small number of rows, I would probably play it safe and use the techniques in the post to force a statistics rebuild and recompilation. The cost of doing so will be pretty small, so unless you're doing something extreme like running it thousands of times per second, I think I'd prefer the safer option.
You did good job Paul. Thank You!
How come I didn't saw this blog post before?! Really interesting reading, plenty of samples and details to play with and reproduce what you comment. We have couple of sp's that maybe could give it a try as it follows a similar pattern related to parameter sniffing and so far we have improved a lot but still having some random issues.
Awesome post.
We had the 2012 version of the plan caching paper here: https://msdn.microsoft.com/en-us/library/dn148262.aspx with you are the reviewer :-)
Thanks very much, Paul, for this and all your other great work that's out there in the public domain!
I've successfully used this approach (update statistics and recompile) where necessary on quite large data warehouse workloads, but today a side-effect caused a performance issue in unit testing, which just illustrates the importance of understanding the internals rather than blindly applying patterns. The recompile option allowed the optimizer to use the value of a local variable in that query, triggering the ascending keys issue. I could add option (optimize for unknown), but it's starting to get a little cumbersome, and a more general purpose alternative (compared to update stats and recompile) seems to be - at the end of the proc - to truncate the temporary table (heap) and then add an index to it (the truncation just to speed up the index add). We can then keep the workaround away from the core business logic, and not have to worry about explicitly recompiling every affected statement, or variable sniffing in those recompilations. This seems to create behaviour closer to what developers might expect from temp tables in stored procs (including cached query plans and more comprehensive execution stats), although you would lose the benefits of temp table caching in high transaction workloads.
hi Paul,
I did not fully understand this sentence "whereas adding RECOMPILE meant the plan would occasionally recompile (when accumulated changes passed RT)." adding recompile will make the statement recompile every execution, isn't it? would you please clarify this part to me, thanks in advance.
Great post.
I was playing around with temp table statistics. Using a modified version of a stored procedure based on some techniques that I found in this article but oddly enough, when I try to pull the statistics for a temp table I get a message saying that:
Could not locate statistics '[whatever_column_name]' in the system catalogs.
Is like the statistics are not created in this case, which is odd, as my sp uses the same DBCC SHOW_STATISTICS idea to gather statistics inside an sp (just like yours does in this article). Here is a simplified example.
-- Declare table variable
CREATE TABLE #temp_table (ID INT)
-- Insert 10K rows
INSERT INTO #temp_table VALUES (@I)
-- Display all rows and output execution plan (now the EstimateRow is just fine!)
SELECT * FROM #temp_table
-- Is the object there
SELECT OBJECT_ID('tempdb..#temp_table')
-- How about statistics
DBCC SHOW_STATISTICS ('tempdb..#temp_table', 'id')
What is wrong with this? why it does not work?


text:
(MCT) — After a mild winter and a scorching, record-setting summer, a question looms: What does winter have in store?
The short answer: Hard to say.
With a witches' brew of variables still unknown, long-range weather forecasts that carry into the deep-freeze months can be a lot like reading tea leaves, experts say.
One thing they do agree on — it's about time for the Chicago area to taste a "hard frost," where the temperature drops to 28 degrees or lower. Temperatures fell below the freezing mark in a handful of suburbs last week, but not in Chicago.
"We are in the frost window," said climatologist James Angel of the Illinois State Water Survey, adding that Chicagoans should expect to wake up one morning after a cold, clear night to frost coated windows and crunchy grass.
"It's coming."
Determining what else may be coming and when it will arrive as trees begin to lose their leaves is more difficult to assess, climatologists say. Still, everybody wants to know what winter has in store.
The stakes are significant. Farmers need to know what to expect. Retailers will consult long-range forecasts before stocking store shelves with shovels and salt, and utility companies will balance energy supplies with projected demand depending how cold the winter is expected to be.
Last winter was among the warmest on record in the Chicago area and in the rest of the country since record keeping began in 1895, according to the National Oceanic and Atmospheric Administration.
The average temperature last winter was 32.8 degrees, 6.4 degrees warmer than the climatological average. Chicago residents used to bundling up through Easter basked in the 70-and 80-degree highs in March, wore sandals on St. Patrick's Day and took kids to the local beaches over spring break.
"We just totally shattered the record temperature for March," said Kevin Birk, a meteorologist for the National Weather Service.
But whether this winter will be a repeat or more characteristically cold is hard to know because the scientific data forecasters use to analyze temperatures and other atmospheric conditions focus mainly just a few days ahead.
Determining a long-range forecast requires the ability to predict how larger climate-scale issues will unfold, such as an El Nino weather pattern that affects ocean temperatures interacting with the atmosphere
Pressure anomalies across the North Atlantic and Arctic also factor in, Birk said.
"There's a lot of things we really don't understand about all the mechanisms and how they work against each other," Birk said. "The way the science is today, we just don't know enough to give a skillful answer."
Still, certain weather prognosticators are willing to stick their necks out a little farther. Sometimes they get it right; other times they miss their mark completely.
AccuWeather.com issued a long-range forecast for the 2011-12 winter with the caveat: "People in Chicago are going to want to move after this winter," according to a news release last fall.
This year, AccuWeather is forecasting a mild winter, with a slight chance of above-normal temperatures.
The Farmers' Almanac predicts a return of "real winter" to parts of the U.S., including the Great Lakes region, and snowstorms between Feb. 12 and 15.
According to the almanac's long-range forecast, winter temperatures in the Chicago area will be slightly higher than average.
Snowfall and precipitation will be less overall, with mid-November, early January and early March the whitest, the almanac says.
"We go out on a limb to say what's going to happen six or 12 months down the road," said Sandi Duncan, managing editor of the almanac.
It's much more than most climatologists are prepared to say about the approaching season at this early date.
Tom Skilling, chief meteorologist for WGN-Ch. 9, said that up until a few weeks ago, he and other forecasters thought a mild winter might lie ahead because there appeared to be a strong El Nino weather pattern steering mild air over the continent.
But today, that pattern looks weak, if not nonexistent. And forecasters have also noticed a dome of warm air in the high latitudes above Greenland, which could signal a more traditional Chicago winter with cold outbreaks and snow, said Skilling, whose forecasts appear daily in the Tribune.
But it's never that simple, Skilling added.
Statistically, warm winters are followed by warm winters two out of three times, he said.
"We don't have all the mysteries of seasonal forecasting worked out yet," Skilling said.
It certainly felt like winter was in the air last weekend, when temperatures dipped below freezing in some areas surrounding the city.
Angel, the Illinois State Water Survey climatologist, said the first hard frost of the year usually hits Chicago by Oct. 15, about a week later than most of the other parts of northern Illinois because densely populated, urban areas stay warmer longer. The warmer temperatures of Lake Michigan also have an insulating effect.
According to data maintained by the water survey, the date of the first hard frost — tracked by temperature rather than observation of the cold crystals glimmering on blades of grass — varies considerably.
Oct. 27 is the average date for the first hard frost, but it has happened as early as Oct. 2 and as late as Dec. 3, according to the water survey.
"If you just bought some awesome mums and you want them to last, if they are portable, put them in your garage," warned Matthew Barrett, who oversees all of the flora grown at the Garfield Park Conservatory.
Barrett said he's watching the forecasts religiously to protect their collection.
"Two or three days before the frost warning, and we have already got the wheels in motion," he said.

subset: commoncrawl


text:
I have hated pugging quite a bit during my WoW life. I think I have even done quite a bit before the new pub system to remind our guild that pugging is bad for your sanity. Then blizzard throws a curve ball and makes the game yet again funner to play by making the idea of pugging cool again.
Two things used to make pugging painful beyond belief. Getting people to the dungeon. Someone would tell you, I am on my way to the stone… only to find out later that they either did not know where the stone was or had not paid for a fast mount yet. That would set the tone for the run and a pug would take hours on top of some more hours. Now the new system lets you to deal only with issues during the run and those can be a lot easier to deal with and you are only subjected to them for 15 mins. So why not talk about some of them here, specially the ones that amuse me.
We have a third or maybe fourth wave of 80s leveling up. I think most people in our guild now have 2 raiding 80s and have a couple more on the way or already there. Some of us have stayed away from the DPS since we have plenty there, but we have several people trying to catch up with Kabara and Theydrin on their ridiculous DK DPS specs.
As a guild we always try to help out people through their last push of levels and when I have a chance I tank even regular dungeons to have people que up faster. So two guildies and I set out to dominate DTK… my favorite instance.
We que up and the first statement out of the pugs that join is like MAAAAAN! THERE GOES MY EXPERIENCE… THERE ARE 80s here, the other one was a mage and started down the same path. My reply was simply, "no worries this will be quick, and remember the door is just a click away we can 3 man this if needed." The non mage pug quickly corrects himself and comes back with, I just want my emblems so its cool with me.
The run was a lot of fun, and since I was tanking and did not need much healing the pulls were big and we moved quickly. The pace was set and we were almost done with the whole run and just cleared a big pull right after the big Dino. There is single pat with mobs all around, but he can be pulled by himself. My plan was to pull him first then kite him to another group and grab agro. The mage had been having fun with his blizzard and was not pulling agro so it was all good.
As I run forward and I am ready to press my charge button I see a fireball flying over my shoulder. I try to recall if the mage has been pulling or not but I had not been paying too much attention since I run DTK almost in autopilot. I stopped and did not press my charge button but instead turned my toon around to face the offending mage.
The mage has cojones, I will give him that. He gets ready to down this elite and did everything to get ready except flex to show me he could handle it. So the mob is running past me and I am static and just waiting to see what he is going to do. I am half waiting for him to either cast something to slow him or freeze him in place when the mob starts to go into a whirlwind.
See, casters are squishy, but a whirldwinding mob in WoW can mow down even plate weares… so a 70s toon in a dungeon wearing green cloth will meet the spirit rez faster than you can say "lightning bolt."
As soon as the mob start spinning the mage stops casting and starts backing away… then the magic word comes! I'm Sorry, I'm Sorry! I promptly trow my weapon and the mob and charge him. Sometimes the best thing to do is to let someone stick the fork into the socket… you might just have the power to take the electricity off and just let themselves give a little shock.


text:
Comprehensive DescriptionRead full entry
Comprehensive Description
Dendrobium orchids are found throughout the western Pacific and east Asia from as far north as Japan to as far south as Tasmania and southern New Zealand, east to Tahiti and west to western India (Lavarack et al. 2000). The genus (as currently delineated) includes more than a thousand species found in widely varying habitats (Lavarack et al. 2000; Adams et al. 2006). Like most other epiphytes, Dendrobium orchids are restricted to areas of moderate to high rainfall (e.g., in tropical lowlands, annual rainfall of more than 150 cm and a dry season of less than 6 months; at higher elevations in the tropics, or in cooler temperate regions, drier conditions can be tolerated). Dendrobium are found from just above the treeline on the highest mountains to the branches of trees overhanging the ocean. They are absent from some of the drier forests and woodlands, deserts and semi-deserts, and alpine and other cold environments. They are mainly inhabitants of primary forest, especially the rainforests of Southeast Asia and New Guinea. Swamp forests (such as those dominated by Melaleuca species) and mangrove forests may also support large numbers of individuals and species. Relatively few Dendrobium species are found in monsoonal forests and woodlands, but populations of species that do occur in these habitats can be dense. The small number of species found in the subalpine shrubbery of tropical mountains are of particular interest in that most of them have brightly colored flowers. Some species are well adapted to disturbed habitats. (Lavarack et al. 2000)
As a consequence of the fact that the genus includes many species that are generally compact, fabulously colorful, and often easy to grow, Dendrobium are among the most horticulturally important orchids. Given the great range of habitats and altitudes at which various species grow, some appropriate species can be found for cultivation in most climates. Although there are many rare and endangered species, Dendrobium are common in both the wild and in gardens in southern Asia; the Malesian Islands (i.e., the islands to the east of Southeast Asia, including New Guinea), the Pacific Islands (the islands south and east of the Solomon Islands, the endemic-rich New Caledonia being the largest of these), and Australia. New Guinea has the greatest diversity of Dendrobium, both in number of species and in diversity per unit area. Lavarack et al. review the historical biogeography of Dendrobium. (Lavarack et al. 2000)
Dendrobium orchids vary in size from tiny creeping plants less than a centimeter high (e.g., D. toressae) to clumped bamboo-like plants several meters tall (e.g., D. discolor). Although most are epiphytes, some grow on rocks or on the ground. All Dendrobium (even the terrestrial species) have coarse, spreading root systems, unlike the tuberous root systems characteristic of terrestrial orchids from temperate regions. (Lavarack et al. 2000)
Dendrobium orchids typically produce large numbers of very small and easily dispersed seeds. These seeds contain almost no food reserves. Seedlings must quickly form mycorrhizal associations with appropriate fungi to supply them with needed nutrition as they develop. (Lavarack et al. 2000)
Perhaps a third of the 30,000 or so orchid species are deceptive, attracting pollinators but then failing to reward them with pollen or nectar. Many of these orchids imitate the scent of rewarding flowers or potential mates. However, one rewardless Dendrobium orchid, Dendrobium sinense, is pollinated by the hornet Vespa bicolor, which it apparently attracts by mimicking the alarm pheromone produced by honeybees, which hornets frequently hunt as food for their larvae (Brodmann et al. 2009).


text:
|Assistant Coach
|Previous College:
|University of Denver '02
|3 years
Brian Keats enters his third season as assistant coach for MIT's swimming and diving program. Brian was a varsity swimmer at the University of Denver where he excelled in the backstroke and individual medley specialties. He graduated in 2002 with a bachelor's degree in Biology. As a student-athlete, he was named team MVP in two consecutive seasons while holding two school records. After graduating, Brian trained and competed for Puerto Rico leading up to the 2004 Olympic Trials in Toronto, Canada.
Currently, Brian directs the aquatics program at the Cambridge YMCA and has been instructing and coaching swimmers of all abilities for the past three years. He is excited to be part of a great swim program here at MIT and looks forward to contributing to the success of the team this year.


text:
lettergenie necesitaba un nuevo diseño de logotipo y lanzó un concurso de diseño en 99designs.
Un ganador ha sido elegido entre 18 diseños de 8 diseñadores freelance.
We are a new web app, software as a service, for creating form letters from popular contact managers, such as Highrise and Microsoft Outlook. Our company is focused on offering dead simple apps that make running a business easier. Our company culture is approachable yet efficient.
Our target audience is small business owners who are price conscious, but also have a sense of style, color and design. Think Target not Walmart.
I have attached a logo design for another brand "myScribe" - we'd like to imitate the color of the pen (aqua) and the font beveling.
Also, need a version with white lettering on transparency for dark background and dark lettering on light background for invoices. EPS, PNG and JPG will do with at least 300 dpi. You're free to be creative on the incorporation of the "genie" element - just nothing to silly or corny. The idea is that our web app creates form letters in a snap, like magic.
It would be great if the icon can be incorporated within the name, "LetterGenie," but it is also acceptable for the icon to be inline before the name.
Our website, http://www.thelettergenie.com, gives a thumbnail of what the app looks like.
Descubre cómo funciona un concurso de diseño u obtén más información sobre nuestros servicios de diseño de logo.


text:
Featured News - Current News - Archived News - News Categories
Following the recent partnership announcement with Twitter Amplify, A&E kicks off the collaboration during the "Duck Dynasty" Christmas special Wednesday, Dec. 11, with exclusive content across social media platforms. Twitter Amplify is a cross-platform tool that allows Twitter users to enjoy exclusive photos and videos, brought to fans by brands.
A&E's social media surrounding this show will feature a holiday-themed social response lab where fans will be asked to tweet #NAUGHTY or #NICE for a chance to get their profile picture incorporated into a customized Christmas graphic or .gif. Custom holiday themed content and animated. gifs will roll out on Twitter and Tumblr from the episode based on funny moments from the show. Facebook and Instagram will also roll out quote cards and memes in real time. Additionally, there will be a "Retweet to Win" sweeps on the "Duck Dynasty" Twitter account where fans will be asked to retweet a specific tweet with tune-in information for a chance to win a "Duck Dynasty" prize pack. Moreover, the popular virtual on-air game "Si Says" will return -when fans see Uncle Si holding a #HEY sign, they'll be asked to tweet #SANTA for a chance to win a "Duck Dynasty" prize pack.
This year's Christmas special features the Robertson's rehearsing for a live nativity for their church for Christmas, which gets off to a bumpy start. Also, Jep advises Willie and Jase on what to get their wives for Christmas.


text:
Deal Seeking Mom Forums
Oops, the Deal Seeking Mom Forums are no longer active. But you'll find all the best deals here at the Deal Seeking Mom Blog:
:: Grocery Grab
Weekly ad listings and coupon matchup.
:: Drugstores
Find the best deals and freebies at CVS, Walgreens and Rite Aid each week.
:: Coupons
Find hot printable coupons to save money on your grocery bill.
:: Online Deals
Find the best online deals and save on the things you love.
:: Freebies
Get free samples sent right to your mailbox!


text:
RemotelyYours needed a new logo design and created a contest on 99designs.
A winner was selected from 86 designs submitted by 30 freelance designers.
Old crappy logo needs to be revamped, would like to keep it "somewhat recognizable" using "deep blue" and "deep purple".
The logo for ISPW (http://www.ispw.com) needs to be modernized - I think you'll agree!We want to keep it "somewhat recognizable" but are open minded. The official colors are "deep blue" and "deep purple".
Have thrown around the ideas of 3D spheres, glass/crystal, reflections.
Their tagline is "Enterprise Software Change Management" but not sure if we want to include that or not.
What they do:
ISPW writes software that manages the development process (compiling, troubleshooting, submitting, bugtesting, etc.) for huge teams of developers (in the thousands). Their customers are big banks, governments, and large development projects that use mainframes.
- Needs to be recognizable as the same company
- Want to use blue & purple
- Can really experiment with the existing lines thru the logo
- Font is pretty open to interpretation
- Want to experiment with 3D
- Like the "water reflection" idea under the logo
- If using rendered 3D/rasters, we want a LARGE copy that would be usable for high resolution print
- Include all fonts, rasters in PSD and vectors in AI/PDF.
- Can be slick, but not wild - selling to big business
- New colors
Find out how a design contest works or learn more about our logo design services.


text:
NEW YORK (AP) — The latest signs of a rebound in housing are sending stocks sharply higher on Wall Street.
The Dow Jones industrial average jumped nearly 116 points to end at 13,900 Tuesday, led by a 6 percent surge in Home Depot. The country's biggest home improvement store chain reported a big increase in earnings.
In another sign that the housing market was gaining steam, the government reported that sales of new homes jumped 16 percent last month to the highest level since July 2008.
That sent the stocks of homebuilders higher. Hovnanian jumped 11 percent.
The Standard & Poor's 500 rose nine points to 1,496. The Nasdaq rose 13 to 3,129.
Two stocks rose for every one that fell on the New York Stock Exchange. Volume was average at 3.8 billion shares.


text:
|Rockville, Md.
|High School:
|Col. Zadok Magruder
|House Affiliation:
Junior · 2011-12
Participated in the three-meter diving event against Cornell and Dartmouth Nov. 14 ... Placed ninth in the one meter prelims (229.65) at the Texas Invitational and also competed in the three meter ... Took third on the three-meter board against Brown Jan. 14 with a score of 284.48 ... Competed on the one meter at the Ivy League Championships.
Sophomore · 2010-11
Placed 10th in the one-meter diving competition and earned All-Ivy League second-team accolades with a second-place result in the three meter competition at the 2011 Ivy League Championships.
Freshman · 2009-10
Captured one and three meter diving titles at Dartmouth-Cornell tri-meet Nov. 14 ... Finished second in the one meter board with a score of 260.25 against Penn Jan. 23.
Before Harvard
Captained diving team junior and senior seasons … Washington Metropolitan Swimming Championship qualifier all four years of high school … Named All-Gazette Diver of the Year in 2008 … Placed first at the Montgomery County high school diving championship and Washington Metropolitan Interscholastic Diving Championship senior year … Recipient of the Magruder Top Achievement Award … AP Scholar with Honor.
Interests include traveling, singing and movies.


text:
Grille closing
Manchester-Boston Regional Airport's Milltown Grille closing after 20 yearsBy PAT GROSSMITH
New Hampshire Union Leader
November 05. 2013 6:42PM
MANCHESTER — The Milltowne Grille, a restaurant frequent flyers have come to rely on over the past two decades at Manchester-Boston Regional Airport, is shutting down in early January, citing a decline in flights from Southwest Airlines and competition from a new restaurant.
But as owners Edward Aloise and his wife, Claudia Rippee, close Milltowne Grille in mid-February they plan to open an Italian wine bar called Campo Enoteca on Elm Street at the site of the former Peking Garden. The restaurateurs also operate Republic, a European-style, farm-to-table restaurant further north on Elm Street.
"It is bittersweet," Aloise said. "Our lease is expiring, and we are not renewing it."
Deputy airport director Brian O'Neill said Aloise and Rippee are great restaurateurs. "We are saddened and very disappointed," he said. "They are a valued partner at the airport and will be missed."
The Milltowne Grille opened at the same time as the new terminal in 1994. The airport recently selected the couple from those sumbitting proposals to continue operating a full-service restaurant at the airport for another 20 years, O'Neill said. But during contract negotiations Aloise and Rippee instead decided to close Milltowne.
The lease expired in July 2012, Aloise said, and the restaurant has been operating on a month-to-month basis. The decision to close was based on economics.
"It's not financially viable," he said. Operating costs for the restaurant are higher because it is located in the secured section of the airport, he said.
Employees have to pass the same background tests given TSA employees, which means Milltowne can't hire someone one day and put him to work the next. And all supplies and food have to be inspected before delivery to the restaurant.
O'Neill said it was Aloise and Rippee's idea to move the entrance to the restaurant from the unsecured side to the secured side, a move airport officials thought was a good one. Their business grew exponentially as a result, he said.
Aloise said one of the biggest factors in the decision was Southwest Airlines' cutting its daily flights to as few as nine — more than three times less than the peak, according to airport officials.
"Your sales are limited to the number of people flying," he said.
The decrease in Southwest flights adversely affected the number of customers, all part of the captured flying audience at the airport. And eight months ago Samuel Adams Manchester Meetinghouse opened on the secured side of the airport, bringing in more competition, Aloise said.
O'Neill said Southwest, which came to Manchester in 1998, topped out at 33 flights a day and, depending on the day of the week and the time of the year, now has as few as nine to 10 daily flights. The average is about 15 to 17 flights a day, he said.
He pointed out that Milltowne operated from 1994 to 2001, when there were fewer passengers then there are today and were successful. While there are fewer flights, O'Neill said Milltowne also faced more competition from Samuel Adams Manchester Meetinghouse.
"They have been doing very well," he said.
And Dunkin' Donuts, which has two sites at the airport, changed its menu to include sandwiches, providing even more competition, O'Neill said.
Aloise said he and his wife put a lot of effort into the airport location, and they are saddened by having to close the restaurant. But he said the economic situation demands it: They could not continue to operate without if Southwest Airlines intendeds to relocate its base of operations to another airport, like Logan International Airport.
There is good news, however. None of the 25 people employed at Milltowne will lose their jobs. Aloise said all of them will be staffing Campo Enoteca.
"We're very fortunate to have some very loyal people," Aloise said. "That's our strength, the longevity of our staff." He said some employees have been with Milltowne for a decade.
He said the Italian wine bar will be as "dramatic to downtown as Republic is. Nobody has seen this kind of Italian food."
Campo Enoteca will feature contemporary Italian cuisine of small plates, fresh pasta made using an imported Italian pasta machine, charcuterie — a culinary specialty that originally referred to pork products such as salami, sausages, and prosciutto — also imported from Italy — antipasti, crostinis and, as is done at Republic, locally sourced fish, chicken and beef.
"We're very excited," he said.
O'Neill said the airport is looking to replace Milltowne with another full-service restaurant and has reached out to other concessions that are interested in expanding. Other restaurants and cafes at the airport include Quiznos, Smuttynose Cafe, Great American Bagel Co. and Starbucks.


text:
You mention that this show is going to be much different from previous shows by you having had taken a new direction of sorts. Can you elaborate some on this?
In past work I concentrated on Man vs. Nature conflicts, politics, social issues and the worries that my children will be inheriting this mess. But I've been fascinated by the cycle of life lately, I don't know, maybe I feel that I'm getting older and getting closer to death while my kids are just starting out their lives.
This body of work is trying to capture some of those feelings, the idea of living your life, having all sorts of adventures and stories, then aging and the inevitability of death looming on the horizon. It's universal, it is repeated everyday, and if you look at any lifeform, you have birth, life, reproduction, death, then the cycle comes around again, and it's been going on on Earth for billions of years. As humans I think we always believe we're living in such an important time in history. In reality we are just a little speck on the timeline.
I always think that my grandchildren will know me, my great grandchildren might kinda know me, but after that my wife and I and even our kids will start to fade away in people's minds. One thousand years from now (if humans have not destroyed the planet) will our country and our times be remembered at all? Surprisingly, I'm comfortable with all of this. It's just the cycle of life. It fascinates me and I'm working on paintings that relate to it.
How has had being a dad affected your work?
It has been one of the best things in my life, and I cannot imagine how I'd be without them. I don't know exactly how it changed my work, I think having kids has made me understand more of how the world works. I understand nature in ways I didn't before kids. I don't know, I'm sure it's made an impact on my work. Looking back I see a big difference in my art post August 2005, that's for sure.
Alot of artists I know don't want kids, and that's cool, they want to keep their lifestyle the same, have less responsibilities, I respect that. And it is easier for sure. But I DO think any stable couple who is the slightest bit interested in having kids should go for it. And don't wuss out, have two kids if you can!
Eating more than I should. I tend to snack a lot when I'm working on a show. It is terrible. I am eating Chinese leftovers as I type this.
I just need to take a break at this point. I'm going to continue painting, I might try out oil painting for a while, but I want to take it slowly and not have the pressure of a show on my shoulders. I have had too many shows in a row the past two years, haven't had a chance to catch my breath. So I don't have anything planned at all. Going to jump into doing more prints, maybe curate some shows and maybe teach a class or two if anyone will hire me. My future is uncertain and it's kinda scary, but I think it's what I need at this point.
No, I don't even know who's playing. I follow baseball, though the past two years I haven't watched much.
When I started painting at 14 I thought the pinnacle of art making was the ability to paint things as realistically as possible, and that's what I worked on for a few years. As I learned more about art history I realized there was so much more to art than being able to render well.
So I tried a bunch of things over the years, from traditional painting to embarrassingly failed attempts at video installations and performance art pieces! It took a while but I realized my strengths were in making visual art, and more importantly, that's what I had the most passion for. In the last ten years I've concentrated heavily on painting, but felt like being a "painter" was too limiting. I was finding used pieces of wood, scratch into my surface, create texture, add collage elements, spraypaint on it; this time I am keeping the pieces really clean and pristine, making each piece precious in a way. I think for this show I wanted to visit my early roots of trying to render forms realistically. I am realizing I am a painter and for the first time embracing it. Aint nuthin' wrong with being a painter!
I am in show mode right now, so my schedule is all fucked up. I have been staying up late to paint in the garage, sleep, and then work all day at my studio which is a few miles from where we live. Usually though I get up with my wife and the kids and help with breakfast and getting everyone ready. Then I work for 8 hours or so and come home- dinner, kids baths, pajamas, etc. Pretty normal "dad" schedule. I actually crave that "dad" schedule part about having weekends off, and I'm going to try to do that when I get back from NYC! Yeah! Gonna take the kidlets to feed the ducks at the park!
|< Prev
|Next >


text:
NEW YORK (AP) — Bebel Gilberto isn't just about bossa nova.
The Rio de Janeiro-raised musician — the daughter of renowned singer and guitarist Joao Gilberto and singer and composer Miucha, — describes her music simply as the "Bebel Sound," an eclectic mix of Brazilian rhythms, soul and electronic music.
"It's music that is easy to listen to. It's music that soothes you, that inspires you. Some of my music is good for dancing, and I definitely will say that is good recipe for a date," Gilberto, 48, said during an interview in a New York City Brazilian restaurant.
Her album "Tudo," released Tuesday, includes 12 songs in Portuguese, English and even some French.
The eclectic mix is understandable. The New York-born musician grew up steeped in bossa nova and U.S. pop rock. Her first album, "Tanto Tempo," was released in 2000, positioning her as an internationally recognized artist. She followed with "Bebel Gilberto" (2004,) "Momento" (2007) and "All in One" (2009).
"I can easily create melodies. For people who can understand music they (the melodies) tend to get kind of a profile of who I am," Gilberto said, adding that inspiration can come to her anytime and anywhere — as it recently did in Tulum, Mexico, where she imagined a song during a long stroll.
This year, Gilberto plans to play in Europe and Brazil before returning to the U.S. in the fall.
Her new work radiates optimism even in its title, which in English means "all" but can also be translated as "very good" or "fantastic."
"I wanted to sing about each little moment, emotion, idea, melody that has been part of my life over the past year," she said. "I am loving life and living more passionately than ever and wanted to share all that."
Claudia Torrens is on Twitter at http://www.twitter.com/ClaudiaTorrens


text: The CamelBak Water Bottle allows you to stay hydrated anytime, anywhere. This innovative water Bottle holds .75L of water and comes in nine stylish colors. The Camelbak Bottle won't spill even if you turn it upside down and leave it in the open position. The big bite valve's proven design contains no moving parts, you simply bite and sip the water...you don't even need to tip. The integrated handle makes this water bottle easy to carry, by clipping it to a carabiner or carrying it with the crook of your finger. The Camelbak Bottle is also easy to use, and easy to clean. Disassemble the parts and your water bottle is safe to clean in the top rack of your dishwasher. The Camelbak Water Bottle fits most cup holders, and attaches to most water filters.


text:
When the unexpected happens from an injury or illness, and physical therapy or cognitive assistance is needed, you can continue to recover at our state-of the-art facility.
At the University Hospital Rehabilitation Center, you will receive the best of both Inpatient Rehabilitation and Outpatient therapy right here in Central New York. There is no need to travel to facilities that are far away and inconvenient for family to visit. Upstate offers these therapy disciplines:
At University Hospital you will receive therapy in the hospital while you are recovering from your injury or procedure. If you need additional rehabilitation services and need to remain in the hospital, you may qualify to come to the 30 bed Acute Inpatient Rehabilitation Unit at the downtown campus or our 20 bed Acute Inpatient Rehabilitation Unit at the Community campus.
The Acute Inpatient Rehabilitation team will provide a combination of physical therapy, occupational therapy, speech and language pathology, and vocational rehabilitation therapy 3 hours a day, 5 days a week to help the patient be the best they are able to be. We admit patients from 12 months of age and up. The staff is a dedicated team of professionals who are experts at treating those with brain injuries, stroke, spinal cord injuries, amputation, major multiple trauma or suffered from other various illnesses. Family members or caregivers are encouraged to participate in your recovery and they are considered part of the rehabilitation team.
If you have further questions we encourage you to visit our facilities in person and take a tour.
University Hospital Rehabilitation Center provides physical therapy, occupational therapy, speech and language pathology, and rehabilitation counselor services at various levels throughout your recovery. In addition to the Acute Inpatient Unit, your care can be continued at the outpatient site at University Hospital, or at one of the comprehensive outpatient programs at five satellite facilities.
Our patients receive specialized care by a highly skilled and dedicated team of rehabilitation professionals including:
Many of our patients are able to return home. If you need further assistance and are unable to return home, you will be assisted in finding the best location to meet your rehabilitation needs.


text:
Tuesday 17th January, 2012
1:20pm to 2:10pm
Software is a human construct and like everything we make it
eventually falls into disrepair. Houses get mould, vermin
infestations, and frightening old wiring. Software projects get
equivalents of these, albeit a few decades faster.
This talk is about the experience of doing a major renovation on
a software relic: the Cyrus IMAP server. Fastmail (now Opera
Software Australia) has been using Cyrus commercially to provide
an IMAP interface to an email store for years now, and over the
last year has significantly contributed to a resurgent effort to
modernise the code and rejuvenate the community. The author
works fulltime on this project and has both observed and
Topics will include: introducing modern software engineering
practices like Continuous Integration, making testing happen,
attracting a developer community, a practical guide on how to
find and fix outdated coding practices (a.k.a. bugs waiting to
happen), and an introduction to paleoentomology. All
illustrated with real world examples.
If your organisation depends on ancient software in need of
revitalising, or if you're just looking for some spare time Open
Source work to keep your hand in, come to this talk and get some
practical tips and a laugh or two.
80 more videos from linux.conf.au 2012
Sign in to add slides, notes or videos to this session
16th–20th January 2012


text:
Skip to Content
Home > Services > Heart & Vascular > Clinical Trials & Research
At Cone Health, you benefit from a heart and vascular team dedicated to continually advancing your care. By taking part in clinical trials and other clinical research, your Cone Health physicians stay up-to-date on the latest treatments and technology so they can give you the best possible care.
The LeBauer Cardiovascular Research Foundation was created in 1991 by Bruce Brodie, MD, Tom Stuckey, MD, and Denise Muncy, RN. For more than 25 years, the Foundation has promoted clinical research in the Piedmont Triad. The foundation was renamed The LeBauer-Brodie Center for Cardiovascular Research and Education in 2016 upon formal integration with the Heart and Vascular Center at Cone Health.
We collaborate with numerous centers in the United States and around the world to bring you promising new ways to prevent, detect, diagnose and treat heart and vascular disease.
As our patient, your well-being is always our top priority. That's why we focus on clinical trials that have high potential for advancing treatment of heart and vascular disease, especially in the areas of:
Trust the experience of doctors who helped set new standards for heart care in the Piedmont Triad and across the country. Starting from the internationally recognized pioneering work of Drs. Bruce Brodie and Richard Weintraub in the 1980's on the timely opening of a heart attack artery, Cone Health has strived to be one of the very best centers in the nation. The Heart and Vascular Center, through its LeBauer-Brodie Center for Cardiovascular Research and Education, has remained a consistent leader in the landmark clinical trials testing the new strategies, drugs, and devices that have defined best practice.
Your doctor may suggest you consider a clinical trial, or you may discover one through your own research. Before joining a cardiovascular clinical trial at Cone Health, you'll meet with our research coordinator to determine whether the trial is a good fit for you. All of our trials have been approved by the Cone Health Institutional Review Board.
Learn more about how clinical trials work or explore clinical trials currently open at Cone Health.
If you think your patient may be eligible for a cardiovascular clinical trial at Cone Health, contact us to learn more or make a referral. We'll work closely with you to provide coordinated, collaborative care. Call 336-832-3799
View More
Contact Us
Share your experience or ask a question
World Class
Awards & Achievements
Follow Us Online
See important information from Cone Health on Non-discrimination and Interpreter Services.
©2018 Cone Health ~ Greensboro, NC


text:
Despite a busy Thursday, business at the beachside ice skating rink isn't matching expectations.
Like a bad skater, the ice-skating experiment in Daytona Beach is still stumbling along.
Despite a busy Thursday, with dozens of families visiting the beachside ice rink, promoter Al Smith of Al Smith Productions said the numbers still aren't matching expectations.
"The people who are coming are enjoying it," Smith said, finding some silver lining Thursday afternoon. "But the numbers are just tailing off (from) last year."
Janelle Schoolcraft, who grew up in Daytona Beach and lives in DeLand now, was one of those enjoying the skating -- and the beachside atmosphere -- on Thursday. She came to the rink for the first time with her sister and family from Orlando -- six kids in all, all off school.
"They're having a blast," she said, also appreciating the Christmas decorations up along A1A. "They've cleaned it up a lot from when we were young."
Smith, who opened the rink last holiday season hoping to draw families to the Boardwalk and Ocean Walk Shoppes during an extended slow period, still hasn't decided if he'll try again next year. He said he won't decide until after skating closes for the winter on Jan. 6.
So far, business is down about 20 percent from last year, he said. (Last year ended up with about 12,600 skaters, and Smith was hoping to reach 14,000 this time.)
If the slow pace holds up, it would make Daytona Beach an outlier: In 30 other markets where the ice-rink company does business, Smith said the average second year's revenue increases 10 to 20 percent.
Daytona's low turnout comes despite a bigger tent with more standing room and a concession stand. The expansions came with a ticket price increase, too, though -- from $10 to $12 per day.
Lately, the crowds haven't been completely discouraging. Two weeks ago, business was lagging even farther behind -- more than 30 percent. On Thursday afternoon, at least, the rink was busy, with 40 to 50 skaters at one point -- lots of them first-timers using rolling walkers to stay upright.
"Since school's been out, we've been very busy," the rink manager, Jerry Potash, said between handing out skates.
Businesses around Ocean Walk Shoppes have been hoping for at least a little boost from the attraction. A mostly empty Sloppy Joe's restaurant was offering to pay for parking for customers who come to eat after skating.
"The slow season's going to be the slow season no matter what you put over here," said Stephanie Brown, a hostess at Sloppy Joe's (who, at least from her seat, thought this year was a little busier than last).
"It's great to have over here, just like it was last year," said Ike Hoke, a manager at Bubba Gump Shrimp Co. "Without it, it definitely would be much slower around the area, so it's nice to have."
Daytona Beach City Commissioner Pam Woods was rooting for the idea to take off, and not only for tourists. "I think it's a great idea, and I do think that as long as we have a lot of different things for people to do in the area -- whether they're visitors or residents -- it's a good thing."
Along with the ice rink, this year's "Holidays at Daytona Beach" includes decorations at the Ocean Walk Shoppes and at the Ocean Center across A1A, also meant to attract families. Smith is also working on this year's New Year's Eve celebration on nearby Main Street, with live music, food, midnight fireworks over the ocean and a ball drop.
In the meantime, he's hoping the remaining 10 days will draw enough numbers to make the rink profitable. It's open 10 a.m. to 10 p.m. every day, with extended hours to 1 a.m. after the clock strikes midnight New Year's Eve.