InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSat, 18 May 2013 21:37:29 GMT20http://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxAs always the real answer is test, test and more tests...But looking at the stats and the output of the 2 statements, I will not be feeling guilty about using temp tables...Thanks for bringing this up and having everyone comment.Sun, 27 Nov 2011 08:34:49 GMTterrykzncshttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxI reckon the solution description to this question needs to be updated ASAP.Many SQL expert agrees and knows that table variable do not cause recompile, whilst the solution clearly describes the performance was caused by table variable is recompiling each time.A very disturbing description to be left as it is for long time because many people reads sqlservercentral and word gets passed around and eventually contributes to a "myth".I'm one of the few who would be very interested to know if someone can prove that table variable causes recompile. Logically speaking, table variables do not have statistics at all and I would wonder the reason for SQL to recompile. The row estimates of table variable in query plan would be 1 anyway.SimonWed, 05 Oct 2011 18:35:13 GMTSimon-413722http://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]SQL Kiwi (10/3/2011)[/b][hr][quote][b]SanDroid (10/3/2011)[/b][hr]Does anyone know what the difference would be between using a WITH statement and a TEMP table?[/quote]A CTE does not (generally) materialize the interim result set. Using a temporary table will materialize the result set, and you'll get distribution statistics too. The reason for the (generally) qualifier is that [i]recursive[/i] CTEs do materialize the set (in a stacked index spool). [b]It is helpful to think of (non-recursive) CTEs as inline VIEW definitions[/b].[/quote]Nice, thanks for that.Tue, 04 Oct 2011 07:49:47 GMTjcrawf02http://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThis question was good.Mon, 03 Oct 2011 15:38:59 GMTDBA_Domhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]L' Eomot Inversé (10/3/2011)[/b][hr] If we had a mechanism for plus votes I would be using it![/quote]I think I've seen this exact conversation recently with quoter and quoted inversed.I just can't remember where... :hehe:Mon, 03 Oct 2011 13:47:25 GMTspaghettidbahttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]SQL Kiwi (10/3/2011)[/b][hr][quote]The skilled database professional is aware of the benefits of each type of temporary structure, and uses each as appropriate. Anyone who says one is [i]always[/i] better than the other is wrong.[/quote]That's 100% true. If we had a mechanism for plus votes I would be using it!The other thing the skilled professional generally does is test and measure to check that his beliefs apply in particular casesMon, 03 Oct 2011 13:10:27 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]SanDroid (10/3/2011)[/b][hr]Does anyone know what the difference would be between using a WITH statement and a TEMP table?[/quote]A CTE does not (generally) materialize the interim result set. Using a temporary table will materialize the result set, and you'll get distribution statistics too. The reason for the (generally) qualifier is that [i]recursive[/i] CTEs do materialize the set (in a stacked index spool). It is helpful to think of (non-recursive) CTEs as inline VIEW definitions.Mon, 03 Oct 2011 13:08:28 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]stewartc-708166 (10/3/2011)[/b][hr]Interesting question, Ron.Thanks [/quote]Yes, it's a good and interesting question[quote]Something to bear in mind: There are numerous factors that influence the choice between table variables and/or temp tables, inter alia:> Data set size (number of columns and rows) - larger datasets work better with temp tables (mainly because these can be indexed);> Availalbe memory vs available drive space (file swapping etc);> IO's;> Persistence (using the data set in other stored procedures)> UDF - one can only use table variables in UDF's[/quote]If this is the sort of message that people take home from this question, that's extremely bad news, because two of the five points are incorrect and a third may be misleading:1)Both temporary tables and table variables can be indexed.2)Memory and drive space usage are the temp table and the table variable live in tempdb 3)The point about more IOs is correct because the creation of the temp table and modifications to it have to be logged (to allow for rollback), but all non-log IO is identical for a temp table and for a table variable.The other two points are indeed valid.However, the question is trying to show people that the forced recompilation when a temp table is used can make a difference - and if people take that lesson away it will be good news.However, I do feel that writing it as one batch with instructions to run it as three batches buried in comments so that the apparent duplicate variable declaration is not in fact a duplicate and won't cause a problem makes it to some extent a trick question (it didn't catch me, but I read comments, probably more carefully that I read code).Another lesson that people could perhaps take away if they thought about how slow these queries are going to be as written is that they should avoid having tables and table variables with no primary key and avoid using heaps (whether for tables or for table variables) when there is a clearly useful cluster structure. Changing the declarations to take account of those simple best practise ground rules - so that "(ID int)" becomes "(ID int primary key clustered)" in all three declarations - will speed up query 1 quite a bit, and result in query 2 and query 1 each taking about the same time (the query with the table variable may be faster that the one with the temp table if the saving on logging is significant; I guess there will be something like a 5 or 10 times speed up on query 1 and maybe a couple of thousand times speed up on query 2, but it's likely to be somewhat hardware dependent). Oh, the wonders of using sensible indexing and clustering!Mon, 03 Oct 2011 13:02:12 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]SQLRNNR (10/3/2011)[/b][hr][quote][b]SanDroid (10/3/2011)[/b][hr] ......Does anyone know what the difference would be between using a WITH statement and a TEMP table?[/quote]Do you mean as in using a CTE or subquery?[/quote]Sorry... I mean using a CTE statement...Mon, 03 Oct 2011 12:29:49 GMTSanDroidhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxFantastic QOD. Thank you!For ease of reading here are what I considered the salient points in the MSDN posting. First, the important difference between table variables and temp tables:[quote]While the “Estimated” and “Actual” query plans are same in most cases, there are some exception. If a table (temporary or permanent) is created in the same batch with the query, SQL Serve has to recompile the query since the query definition is unknown when the batch is compiled the first time. This is not the case for table variables (and that was the main reasons SQL Server 2005 introduce them – to reduce recompilations when unnecessary). [/quote]Then, why this makes a difference in the sample situation:[quote]You will see that the actual plan for script 1 is the same as estimated plan and took substantially longer than the script 2 to complete. The actual execution plan for Script 2 is very different from its estimated plan. The actual execution plan for script 2 uses Hash Match to execute the Anti Semi Join at the top of the plan. There is a table scan of the temporary table #Tmp1 at the top of the plan building the hash table. If you examine the properties of this scan you will find out that the number of Estimated rows is 20000 (was 1 in the Estimated plan as well as it is 1 for the table variable plan). [/quote]Finally, the bottom-line advice, which is that generally temp tables are preferred to table variables, but which I also interpret as pretty much what some others have said here as "look at the ACTUAL execution plan and TEST, TEST, TEST":[quote]When examining query plans be careful to consider possible plan change during the batch execution due to recompiles. Bear in mind that while table variables are not causing recompiles, you may need just the opposite to get the best query plan. You should always use temporary tables in your queries unless you intentionally want to avoid query recompilation and you are confident query variable will give you a good plan. Introduction of statement level recompilation in SQL Server 2005 substantially lowered the need to use table variables in your queries. [/quote]Mon, 03 Oct 2011 12:28:05 GMTjohn.arnotthttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]SQL Kiwi (10/3/2011)[/b][hr][quote][b]Thomas Abraham (10/3/2011)[/b][hr]So, now I'm a bit confused. Just when am I supposed to use table variables?[/quote]Whenever they suit the requirement better than a temporary table :-)Wayne Sheffield wrote an excellent SSC article comparing the two: [url]http://www.sqlservercentral.com/articles/Temporary+Tables/66720/[/url]The skilled database professional is aware of the benefits of each type of temporary structure, and uses each as appropriate. Anyone who says one is [i]always[/i] better than the other is wrong.[/quote]From the source referenced above[quote]So, what should I use?Microsoft recommends using table variables (in Reference 4). If the number of rows that you are going to be inserting into the table is very small, then use a table variable. Most of the “internet gurus” will tell you to have less than 100 records as a guideline, as this is where the lack of statistics start to mess up a query – but they will also tell you to test your specific needs against both methods. Some people will only use table variables within user-defined table functions (which require them). If you can use an index from either a PRIMARY KEY or UNIQUE constraint on a table variable, then you could get excellent performance from table variables that contain tens of thousands of records. This is primarily true if you don’t have to join the table variable to another table. When you start joining the table variable to other tables, then the cardinality error frequently results in a bad execution plan, which gets worse the more complex the query is, and the larger the row count is.[/quote]That's about right for a "rule of thumb" - one that I will, of course, not assume is always correct. Thanks for the reference!Mon, 03 Oct 2011 12:25:14 GMTThomas Abrahamhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]Thomas Abraham (10/3/2011)[/b][hr]So, now I'm a bit confused. Just when am I supposed to use table variables?[/quote]Whenever they suit the requirement better than a temporary table :-)Wayne Sheffield wrote an excellent SSC article comparing the two: [url]http://www.sqlservercentral.com/articles/Temporary+Tables/66720/[/url]The skilled database professional is aware of the benefits of each type of temporary structure, and uses each as appropriate. Anyone who says one is [i]always[/i] better than the other is wrong.Mon, 03 Oct 2011 11:48:06 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThe explanation:[b]The reason is that the table variable causes a recompilation.[/b]...is entirely backwards, as reading the explanatory link shows. An unfortunate typo, perhaps?Mon, 03 Oct 2011 11:38:19 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]Lynn Pettis (10/3/2011)[/b][hr]... There may also be other reasons, but it really comes down to testing, testing, and more testing.[/quote]I agree with you!!!!!Mon, 03 Oct 2011 10:16:07 GMTrfr.ferrarihttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThat was a great question!Got it wrong, as usual.However, I think the reason behind the slowness of the table variable is the poor cardinality estimation more than the recompile itself. Had it been recompiled to an accurate plan, it would have performed just as fast as the temp table.Mon, 03 Oct 2011 10:07:48 GMTspaghettidbahttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThanks for the question Ron.Mon, 03 Oct 2011 10:03:00 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]SanDroid (10/3/2011)[/b][hr][quote][b]Lynn Pettis (10/3/2011)[/b][hr][quote][b]SanDroid (10/3/2011)[/b][hr]Nice question. I heard this was supposed to change in 2008. Not suprised it did not.Becuase of this we always remove table variables from any code we get.Table Variables have a use and need in some functions, but in a stored procedure they have little to no use.[/quote]I'll agree to disagree. I think it really depends on what they are being used for in the stored procedure. If you are trying to capture information using the OUTPUT clause of an INSERT/UPDATE/DELETE/MERGE operation regardless of a commit or rollback of the operation, then you do need the table variables.There may also be other reasons, but it really comes down to testing, testing, and more testing.[/quote]I have to agree on the test and more testing part. I have yet to find a test case where table variables are faster on average.I am sure there are times when using a table varible is needed.Does anyone know what the difference would be between using a WITH statement and a TEMP table?[/quote]Do you mean as in using a CTE or subquery?Mon, 03 Oct 2011 10:02:34 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]abhiraami.kasilakshmi (10/3/2011)[/b][hr]The site which i referred regarding this says that table variables are stored only in memory. so the access time for a table variable can be faster than the time it takes to access a temporary table.Note: http://searchsqlserver.techtarget.com/tip/Temporary-tables-in-SQL-Server-vs-table-variablesbut when i tried to execute the query it results both as same....So which one is the correct answer...[/quote]Table variables being stored only in memory is a myth. Check out the link posted already for Gail Shaws article debunking that myth.Mon, 03 Oct 2011 09:58:26 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxtks for the question. I ran into a similar issue to that reported on the reference article when migrating code from 2000 to 2005/2008. :crazy:agree with you Lynn -context is an important consideration before we declare table variables dead. ;-)Mon, 03 Oct 2011 09:54:52 GMTOzYbOi d(-_-)bhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThanks for the question.Mon, 03 Oct 2011 09:41:40 GMTTrey Stakerhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxNice question. We rarely use table variables so I am always interested in questions regarding performance using them versus using a temp table. Personally I have seen few instances where the table variable outperforms the temp table. As others mentioned though, they do have their place and testing is the best way to tell if you should use one or not.Mon, 03 Oct 2011 09:37:05 GMTKWymorehttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]Lynn Pettis (10/3/2011)[/b][hr][quote][b]SanDroid (10/3/2011)[/b][hr]Nice question. I heard this was supposed to change in 2008. Not suprised it did not.Becuase of this we always remove table variables from any code we get.Table Variables have a use and need in some functions, but in a stored procedure they have little to no use.[/quote]I'll agree to disagree. I think it really depends on what they are being used for in the stored procedure. If you are trying to capture information using the OUTPUT clause of an INSERT/UPDATE/DELETE/MERGE operation regardless of a commit or rollback of the operation, then you do need the table variables.There may also be other reasons, but it really comes down to testing, testing, and more testing.[/quote]I have to agree on the test and more testing part. I have yet to find a test case where table variables are faster on average.I am sure there are times when using a table varible is needed.Does anyone know what the difference would be between using a WITH statement and a TEMP table?Mon, 03 Oct 2011 09:28:19 GMTSanDroidhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxAlso, thanks for an interesting question: performance has been my professional hobby for years.Mon, 03 Oct 2011 09:27:05 GMTRevenanthttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]Lynn Pettis (10/3/2011)[/b][hr]. . . There may also be other reasons, but it really comes down to testing, testing, and more testing.[/quote]Absolutely correct, Lynn.Mon, 03 Oct 2011 09:26:13 GMTRevenanthttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]SanDroid (10/3/2011)[/b][hr]Nice question. I heard this was supposed to change in 2008. Not suprised it did not.Becuase of this we always remove table variables from any code we get.Table Variables have a use and need in some functions, but in a stored procedure they have little to no use.[/quote]I'll agree to disagree. I think it really depends on what they are being used for in the stored procedure. If you are trying to capture information using the OUTPUT clause of an INSERT/UPDATE/DELETE/MERGE operation regardless of a commit or rollback of the operation, then you do need the table variables.There may also be other reasons, but it really comes down to testing, testing, and more testing.Mon, 03 Oct 2011 09:17:41 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxNice question. I heard this was supposed to change in 2008. Not suprised it did not.Becuase of this we always remove table variables from any code we get.Table Variables have a use and need in some functions, but in a stored procedure they have little to no use.Mon, 03 Oct 2011 08:57:32 GMTSanDroidhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThanks to all, including Ron, Mark & Jack, for their responses.I had just switched over to using more table variables, and will be more reluctant to use them going forward.Mon, 03 Oct 2011 08:11:41 GMTThomas Abrahamhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]Thomas Abraham (10/3/2011)[/b][hr][quote][b]sknox (10/3/2011)[/b][hr]The answer is correct but the explanation ("The reason is that the table variable causes a recompilation") is 100% wrong.The reason the table variable code is so slow is precisely because it [b]does not[/b] produce a recompile -- as mentioned in the very blog article linked to in the answer.So the temp table step recompiles and runs based on an estimated (and actual) 20,000 rows.The table variable step [b]does not[/b] recompile and runs based on an estimated 1 instead of an actual 20,000 rows -- producing an inefficient query plan, leading to a slow query.[/quote]That makes more sense to me, especially in light of the results. As the table size gets smaller, i.e. closer to the estimated size of 1, it begins to run as quickly as the optimizer "expected".While I would love to thoroughly test the performance of all possible versions of every proc I write, I'm not given that much time. So, while there are times where I can do so, in most cases, it's useful to have rules of thumb that I can rely on, and only have to test alternatives when the performance from using these rules is different than expected.For example, from the results I saw in the testing suggested, I might conclude that I can "safely" use a table variable for small result sets, or for data sets that will not be used in large joins.[/quote]The key is to test. If I'm not going to index beyond adding PK I start with a table variable and convert if I have performance issues. Also you can look at what is your bottleneck. If it is CPU perhaps you don't want the recompile. Honestly I probably use table variables too much and this question shows that I should reconsider my practices. When I ran the code the temp table was about 100+ times faster (2008R2).Mon, 03 Oct 2011 08:01:33 GMT Jack Corbetthttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]sknox (10/3/2011)[/b][hr]The answer is correct but the explanation ("The reason is that the table variable causes a recompilation") is 100% wrong.The reason the table variable code is so slow is precisely because it [b]does not[/b] produce a recompile -- as mentioned in the very blog article linked to in the answer.So the temp table step recompiles and runs based on an estimated (and actual) 20,000 rows.The table variable step [b]does not[/b] recompile and runs based on an estimated 1 instead of an actual 20,000 rows -- producing an inefficient query plan, leading to a slow query.[/quote]That makes more sense to me, especially in light of the results. As the table size gets smaller, i.e. closer to the estimated size of 1, it begins to run as quickly as the optimizer "expected".While I would love to thoroughly test the performance of all possible versions of every proc I write, I'm not given that much time. So, while there are times where I can do so, in most cases, it's useful to have rules of thumb that I can rely on, and only have to test alternatives when the performance from using these rules is different than expected.For example, from the results I saw in the testing suggested, I might conclude that I can "safely" use a table variable for small result sets, or for data sets that will not be used in large joins.Mon, 03 Oct 2011 07:53:42 GMTThomas Abrahamhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]Thomas Abraham (10/3/2011)[/b][hr]I got it wrong, so I tested it on my own system. (2008 R2 - 2005 not available)Results for table variable, in ms: 80800, 80203, & 79523Results for temp table, in ms: 463, 450, 470So, now I'm a bit confused. Just when am I supposed to use table variables??[/quote]In my opinion, very very little.Need to use them in UDF's, need to use them as Table Valued Parameters to a stored proc. Aside from that, I never use them. Too many benefits temp tables give that table variables don't. While I rarely see enough of a performance benefit from putting non-clustered indexes on a temp table, sometimes the cost of the index is less than the time saved by the query because of the index. Temp tables have statistics as well. [b]The biggest reason people seem to use them has to do with the myth that table variables don't go to disk.[/b] Mon, 03 Oct 2011 07:48:19 GMTmtassinhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThe answer is correct but the explanation ("The reason is that the table variable causes a recompilation") is 100% wrong.The reason the table variable code is so slow is precisely because it [b]does not[/b] produce a recompile -- as mentioned in the very blog article linked to in the answer.So the temp table step recompiles and runs based on an estimated (and actual) 20,000 rows.The table variable step [b]does not[/b] recompile and runs based on an estimated 1 instead of an actual 20,000 rows -- producing an inefficient query plan, leading to a slow query.Mon, 03 Oct 2011 07:44:07 GMTsknoxhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxInteresting question and answer, I learned something today. Thanks.Mon, 03 Oct 2011 07:40:29 GMTDaniel Bowlinhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]yogesh.balasubramanian (10/3/2011)[/b][hr]I see a relavent article and it seems like table variable is much faster than temp table. Ref: [url]http://sqlserverperformance.idera.com/uncategorized/performance-comparison-temp-tables-table-variables-sql-server/[/url] :unsure: Confused on which one is better?[/quote]One item that the question hoped to illustrate is that like most things in SQL SERVER (T-SQL) [b]"IT DEPENDS"[/b]For example - additional testing using SQL Server 2008 [code="sql"] Processing Time (in milliseconds)#Rows Table Variable Temp Table20,000 68,773 386 2,000 633 70 200 33 23 20 16 20[/code]Add in further modifications to the Temp Table, such as an index, and the results change again. So in the real world, do not depend uponassumptions, or what others say is the best method. Test YOUR solution and test it again and again to insure it is the better solution before placing it in a production DBMon, 03 Oct 2011 07:20:16 GMTbitbucket-25253http://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxYou guys really need to learn english. There was rarely, if ever, a better written question.It clearly stated to execute 3 batches separately with begin / end points in the code.I just would like to add to the short explaination that the recompile speeds up the query because the row estimation is better which gives a different & better plan to execute.Table variables estimate to 1 row which is way wrong in this case and causes the "bad" plan.Mon, 03 Oct 2011 07:10:49 GMTNinja's_RGR'ushttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThe Inserts both execute at about the same speed. It is the "Select where not in" statement that is considerably slower with the table variable. So I think the point of the question was not how fast the insert runs but how fast the select runs.Mon, 03 Oct 2011 07:05:32 GMTtabinschttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxOops, where are my manners. Thank you sir, may I please have another? (Question, that is.)Mon, 03 Oct 2011 06:09:10 GMTThomas Abrahamhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxI got it wrong, so I tested it on my own system. (2008 R2 - 2005 not available)Results for table variable, in ms: 80800, 80203, & 79523Results for temp table, in ms: 463, 450, 470So, now I'm a bit confused. Just when am I supposed to use table variables??Mon, 03 Oct 2011 06:08:09 GMTThomas Abrahamhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxMissed it. Thanks for the question.Mon, 03 Oct 2011 05:22:44 GMTBritt Cluffhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspx[quote][b]tommyh (10/3/2011)[/b] Strange effect on 2008 i must say. /T[/quote]As known, Microsoft was changed work with tempDB since SQL 2005, so it is possible, that time dimensions in SQL 2000 differ with time dimensions in SQL 2k5, 2k8, 2k11 etc. Excuse my bad english :-)Mon, 03 Oct 2011 03:29:58 GMTdgvozdetskyhttp://www.sqlservercentral.com/Forums/Topic1184177-1222-1.aspxThe site which i referred regarding this says that table variables are stored only in memory. so the access time for a table variable can be faster than the time it takes to access a temporary table.Note: http://searchsqlserver.techtarget.com/tip/Temporary-tables-in-SQL-Server-vs-table-variablesbut when i tried to execute the query it results both as same....So which one is the correct answer...Mon, 03 Oct 2011 03:20:53 GMTabhiraami.kasilakshmi