DELETE प्रदर्शन पर प्रभाव क्यों छोड़ता है?

20

अंत में एक @table चर और एक # तालिका के बीच प्रदर्शन की तुलना करने के लिए एक परीक्षण स्क्रिप्ट है। मुझे लगता है कि मैंने इसे सही ढंग से सेट किया है - प्रदर्शन समय को DELETE / TRUNCATE कमांड के बाहर ले जाया जाता है । मुझे जो परिणाम मिल रहे हैं, वे इस प्रकार हैं (मिलीसेकंड में बार)।

@Table Variable  #Temp (delete)  #Temp (truncate)
---------------  --------------  ----------------
5723             5180            5506
15636            14746           7800
14506            14300           5583
14030            15460           5386
16706            16186           5360

बस यह सुनिश्चित करने के लिए कि मैं समझदार हूं, यह दिखाता है कि CURRENT_TIMESTAMP (उर्फ GetDate()) को बयान के समय लिया जाता है, बैच का नहीं, इसलिए SET @StartTime = CURRENT_TIMESTAMPकथन के साथ TRUNCATE / DELETE के बीच कोई बातचीत नहीं होनी चाहिए ।

select current_timestamp
waitfor delay '00:00:04'
select current_timestamp

-----------------------
2012-10-21 11:29:20.290

-----------------------
2012-10-21 11:29:24.290

यह पहली दौड़ और बाद के रन के बीच कूद में काफी सुसंगत है जब DELETE का उपयोग तालिका को साफ़ करने के लिए किया जाता है। DELETE की मेरी समझ में मुझे क्या याद आ रहा है ? मैंने इसे कई बार दोहराया है, आदेश की अदला-बदली की, विकास की आवश्यकता नहीं होने के लिए टेम्पर्डब का आकार दिया।

CREATE TABLE #values (
  id int identity primary key, -- will be clustered
  name varchar(100) null,
  number int null,
  type char(3) not null,
  low int null,
  high int null,
  status smallint not null
);
GO
SET NOCOUNT ON;

DECLARE @values TABLE (
  id int identity primary key clustered,
  name varchar(100) null,
  number int null,
  type char(3) not null,
  low int null,
  high int null,
  status smallint not null
);
DECLARE  @ExecutionTime  TABLE(      Duration bigINT    ) 
DECLARE  @StartTime DATETIME,  @i INT = 1; 
WHILE (@i <= 5) 
  BEGIN 
    DELETE @values;
    DBCC freeproccache With NO_InfoMSGS;
    DBCC DROPCLEANBUFFERS With NO_InfoMSGS;
    SET @StartTime = CURRENT_TIMESTAMP -- alternate getdate() 
    /****************** measured process ***********************/ 

    INSERT @values SELECT a.* FROM master..spt_values a join master..spt_values b on b.type='P' and b.number < 1000;

    /**************** end measured process *********************/ 
    INSERT @ExecutionTime 
    SELECT DurationInMilliseconds = datediff(ms,@StartTime,CURRENT_TIMESTAMP) 
    SET @i +=  1 
  END -- WHILE 

SELECT DurationInMilliseconds = Duration FROM   @ExecutionTime 
GO 

-- Temporary table
DECLARE  @ExecutionTime  TABLE(      Duration bigINT    ) 
DECLARE  @StartTime DATETIME,  @i INT = 1; 
WHILE (@i <= 5) 
  BEGIN 
    delete #values;
    -- TRUNCATE TABLE #values;
    DBCC freeproccache With NO_InfoMSGS;
    DBCC DROPCLEANBUFFERS With NO_InfoMSGS;
    SET @StartTime = CURRENT_TIMESTAMP -- alternate getdate() 
    /****************** measured process ***********************/ 

    INSERT #values SELECT a.* FROM master..spt_values a join master..spt_values b on b.type='P' and b.number < 1000;

    /**************** end measured process *********************/ 
    INSERT @ExecutionTime 
    SELECT DurationInMilliseconds = datediff(ms,@StartTime,CURRENT_TIMESTAMP) 
    SET @i +=  1 
  END -- WHILE 

SELECT DurationInMilliseconds = Duration FROM   @ExecutionTime 
GO

DROP TABLE  #values 
SET NOCOUNT OFF;
sql-server  performance  sql-server-2012  delete  truncate 
— 孔夫子
स्रोत

जवाबों:

20

यह अंतर केवल तब लागू होता है जब वस्तु B + वृक्ष हो। primary keyटेबल चर पर हटाते समय यह एक ढेर है मुझे निम्नलिखित परिणाम मिले

2560
2120
2080
2130
2140

लेकिन पीके के साथ मुझे अपने परीक्षणों में एक समान पैटर्न मिला और साथ ही नीचे दिए गए विशिष्ट परिणामों के साथ।

+--------+--------+---------+-------------------+
| @table | #table | ##table | [permanent_table] |
+--------+--------+---------+-------------------+
|   2670 |   2683 |    9603 |              9703 |
|   6823 |   6840 |    9723 |              9790 |
|   6813 |   6816 |    9626 |              9703 |
|   6883 |   6816 |    9600 |              9716 |
|   6840 |   6856 |    9610 |              9673 |
+--------+--------+---------+-------------------+

मेरा सिद्धांत है कि स्थानीय अस्थायी B + पेड़ों पर थोक आवेषण करते समय कुछ अनुकूलन उपलब्ध है जो केवल तब लागू होता है जब यह पहले से ही आवंटित पृष्ठों को नहीं करता है।

मैं इसे निम्नलिखित टिप्पणियों पर आधारित करता हूं।

  1. जब अपने परीक्षण कोड के विभिन्न संस्करणों चल मैं केवल के साथ इस पैटर्न देखा @table_variablesऔर #tempटेबल। में नहीं स्थायी टेबल tempdbहै और न ही ##टेबल।

  2. धीमे प्रदर्शन को पाने के लिए पहले से बड़ी संख्या में पंक्तियों को जोड़ना और हटाना आवश्यक नहीं है। बस एक ही पंक्ति को जोड़ने और इसे वहां छोड़ने के लिए पर्याप्त है।

  3. TRUNCATE तालिका से सभी पृष्ठ हटाता है। DELETEतालिका के अंतिम पृष्ठ को अस्वीकृत नहीं किया जाएगा।

  4. वीएस 2012 प्रोफाइलर का उपयोग करना दिखाता है कि तेज मामले में SQL सर्वर एक अलग कोड पथ का उपयोग करता है। में 36% समय व्यतीत होता हैsqlmin.dll!RowsetBulk::InsertRowsqlmin.dll!RowsetNewSS::InsertRow धीमे मामले के लिए खर्च किए गए समय के बनाम 61% में खर्च किया जाता है।

चल रहा है 

SELECT * 
FROM sys.dm_db_index_physical_stats(2,OBJECT_ID('tempdb..#values'),1,NULL, 'DETAILED')

हटाने के बाद

+-------------+------------+--------------+--------------------+
| index_level | page_count | record_count | ghost_record_count |
+-------------+------------+--------------+--------------------+
|           0 |          1 |            0 |                  1 |
|           1 |          1 |            1 |                  0 |
|           2 |          1 |            1 |                  0 |
+-------------+------------+--------------+--------------------+

मैंने पाया कि समय की विसंगति को कुछ हद तक कम करना संभव था ट्रेस ध्वज 610 सक्षम ।

इसके बाद के आवेषणों के लिए लॉगिंग की मात्रा को कम करने का प्रभाव था (350 एमबी से 103 एमबी तक नीचे क्योंकि यह अब व्यक्तिगत सम्मिलित पंक्ति मूल्यों को लॉग नहीं करता है), लेकिन इससे केवल दूसरे और बाद के लिए समय में मामूली सुधार हुआ @table,#table मामलों के और अंतर अभी भी बना हुआ है। ट्रेस ध्वज ने आवेषण के सामान्य प्रदर्शन को अन्य दो तालिका प्रकारों में महत्वपूर्ण रूप से सुधार दिया।

+--------+--------+---------+-------------------+
| @table | #table | ##table | [permanent_table] |
+--------+--------+---------+-------------------+
|   2663 |   2670 |    5403 |              5426 |
|   5390 |   5396 |    5410 |              5403 |
|   5373 |   5390 |    5410 |              5403 |
|   5393 |   5410 |    5406 |              5433 |
|   5386 |   5396 |    5390 |              5420 |
+--------+--------+---------+-------------------+

लेन-देन लॉग में देखने से मैंने देखा कि खाली स्थानीय अस्थायी तालिकाओं के खिलाफ प्रारंभिक आवेषण और भी कम से कम लॉग इन (96 एमबी पर) लगते हैं।

विशेष रूप से इन तेज़ आवेषण में धीमे मामलों की तुलना में केवल 657लेनदेन ( LOP_BEGIN_XACT/ LOP_COMMIT_XACTजोड़े) थे 10,000। विशेष रूप से LOP_FORMAT_PAGEसंचालन में बहुत कम लगता है। धीमे मामलों में 10,270केवल इसके साथ तुलना में तालिका (प्रत्येक) के प्रत्येक पृष्ठ के लिए इसके लिए लेनदेन लॉग प्रविष्टि है4 में फास्ट ऐसी प्रविष्टियों ।

सभी तीन मामलों में उपयोग किए गए लॉग निम्नानुसार थे (मैंने पाठ की मात्रा को कम करने के लिए सिस्टम बेस तालिकाओं में अपडेट के लिए लॉग रिकॉर्ड को हटा दिया है लेकिन वे अभी भी योग में शामिल हैं)

@table_var(96.5 एमबी) के खिलाफ पहली प्रविष्टि लॉगिंग

+-----------------------+----------+----------------------------------------------+---------------+---------+
|       Operation       | Context  |                AllocUnitName                 | Size in Bytes |   Cnt   |
+-----------------------+----------+----------------------------------------------+---------------+---------+
| LOP_BEGIN_XACT        | LCX_NULL | NULL                                         |         83876 |     658 |
| LOP_COMMIT_XACT       | LCX_NULL | NULL                                         |         34164 |     657 |
| LOP_CREATE_ALLOCCHAIN | LCX_NULL | NULL                                         |           120 |       3 |
| LOP_FORMAT_PAGE       | LCX_HEAP | dbo.#531856C7                                |            84 |       1 |
| LOP_FORMAT_PAGE       | LCX_IAM  | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |            84 |       1 |
| LOP_FORMAT_PAGE       | LCX_IAM  | dbo.#531856C7                                |            84 |       1 |
| LOP_FORMAT_PAGE       | LCX_IAM  | Unknown Alloc Unit                           |            84 |       1 |
| LOP_HOBT_DDL          | LCX_NULL | NULL                                         |           216 |       6 |
| LOP_HOBT_DELTA        | LCX_NULL | NULL                                         |           320 |       5 |
| LOP_IDENT_NEWVAL      | LCX_NULL | NULL                                         |     100240000 | 2506000 |
| LOP_INSERT_ROWS       | LCX_HEAP | dbo.#531856C7                                |            72 |       1 |
| LOP_MODIFY_ROW        | LCX_IAM  | dbo.#531856C7                                |            88 |       1 |
| LOP_MODIFY_ROW        | LCX_PFS  | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |        158592 |    1848 |
| LOP_MODIFY_ROW        | LCX_PFS  | dbo.#531856C7                                |            80 |       1 |
| LOP_MODIFY_ROW        | LCX_PFS  | Unknown Alloc Unit                           |        216016 |    2455 |
| LOP_SET_BITS          | LCX_GAM  | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |         84360 |    1406 |
| LOP_SET_BITS          | LCX_GAM  | Unknown Alloc Unit                           |        147120 |    2452 |
| LOP_SET_BITS          | LCX_IAM  | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |         84360 |    1406 |
| LOP_SET_BITS          | LCX_IAM  | Unknown Alloc Unit                           |        147120 |    2452 |
| Total                 | NULL     | NULL                                         |     101209792 | 2519475 |
+-----------------------+----------+----------------------------------------------+---------------+---------+

बाद में आवेषण लॉगिंग TF 610 ऑफ (350 एमबी)

+-----------------------+--------------------+----------------------------------------------+---------------+---------+
|       Operation       |      Context       |                AllocUnitName                 | Size in Bytes |   Cnt   |
+-----------------------+--------------------+----------------------------------------------+---------------+---------+
| LOP_BEGIN_CKPT        | LCX_NULL           | NULL                                         |            96 |       1 |
| LOP_BEGIN_XACT        | LCX_NULL           | NULL                                         |       1520696 |   12521 |
| LOP_COMMIT_XACT       | LCX_NULL           | NULL                                         |        651040 |   12520 |
| LOP_CREATE_ALLOCCHAIN | LCX_NULL           | NULL                                         |            40 |       1 |
| LOP_DELETE_SPLIT      | LCX_INDEX_INTERIOR | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |          2160 |      36 |
| LOP_END_CKPT          | LCX_NULL           | NULL                                         |           136 |       1 |
| LOP_FORMAT_PAGE       | LCX_HEAP           | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |        859236 |   10229 |
| LOP_FORMAT_PAGE       | LCX_IAM            | Unknown Alloc Unit                           |            84 |       1 |
| LOP_FORMAT_PAGE       | LCX_INDEX_INTERIOR | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |          3108 |      37 |
| LOP_HOBT_DDL          | LCX_NULL           | NULL                                         |           648 |      18 |
| LOP_HOBT_DELTA        | LCX_NULL           | NULL                                         |        657088 |   10267 |
| LOP_IDENT_NEWVAL      | LCX_NULL           | NULL                                         |     100239960 | 2505999 |
| LOP_INSERT_ROWS       | LCX_CLUSTERED      | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |     258628000 | 2506000 |
| LOP_INSERT_ROWS       | LCX_HEAP           | dbo.#531856C7                                |            72 |       1 |
| LOP_INSERT_ROWS       | LCX_INDEX_INTERIOR | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |       1042776 |   10302 |
| LOP_MODIFY_HEADER     | LCX_HEAP           | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |        859236 |   10229 |
| LOP_MODIFY_HEADER     | LCX_INDEX_INTERIOR | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |          3192 |      38 |
| LOP_MODIFY_ROW        | LCX_IAM            | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |           704 |       8 |
| LOP_MODIFY_ROW        | LCX_PFS            | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |        934264 |   11550 |
| LOP_MODIFY_ROW        | LCX_PFS            | Unknown Alloc Unit                           |        783984 |    8909 |
| LOP_SET_BITS          | LCX_GAM            | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |         76980 |    1283 |
| LOP_SET_BITS          | LCX_GAM            | Unknown Alloc Unit                           |        534480 |    8908 |
| LOP_SET_BITS          | LCX_IAM            | dbo.#4F47C5E3.PK__#4F47C5E__3213E83F51300E55 |         76980 |    1283 |
| LOP_SET_BITS          | LCX_IAM            | Unknown Alloc Unit                           |        534480 |    8908 |
| LOP_SHRINK_NOOP       | LCX_NULL           | NULL                                         |            32 |       1 |
| LOP_XACT_CKPT         | LCX_NULL           | NULL                                         |            92 |       1 |
| Total                 | NULL               | NULL                                         |     367438748 | 5119297 |
+-----------------------+--------------------+----------------------------------------------+---------------+---------+

टीएफ 610 पर बाद के आवेषण लॉगिंग (103 एमबी)

+-------------------------+-------------------------+----------------------------------------------+---------------+---------+
|        Operation        |         Context         |                AllocUnitName                 | Size in Bytes |   Cnt   |
+-------------------------+-------------------------+----------------------------------------------+---------------+---------+
| LOP_BEGIN_CKPT          | LCX_NULL                | NULL                                         |           192 |       2 |
| LOP_BEGIN_XACT          | LCX_NULL                | NULL                                         |       1339796 |   11099 |
| LOP_BULK_EXT_ALLOCATION | LCX_NULL                | NULL                                         |         20616 |     162 |
| LOP_COMMIT_XACT         | LCX_NULL                | NULL                                         |        577096 |   11098 |
| LOP_CREATE_ALLOCCHAIN   | LCX_NULL                | NULL                                         |            40 |       1 |
| LOP_DELETE_SPLIT        | LCX_INDEX_INTERIOR      | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |          2160 |      36 |
| LOP_END_CKPT            | LCX_NULL                | NULL                                         |           272 |       2 |
| LOP_FORMAT_PAGE         | LCX_BULK_OPERATION_PAGE | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |        863520 |   10280 |
| LOP_FORMAT_PAGE         | LCX_IAM                 | Unknown Alloc Unit                           |            84 |       1 |
| LOP_FORMAT_PAGE         | LCX_INDEX_INTERIOR      | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |          3108 |      37 |
| LOP_HOBT_DELTA          | LCX_NULL                | NULL                                         |        666496 |   10414 |
| LOP_IDENT_NEWVAL        | LCX_NULL                | NULL                                         |     100239960 | 2505999 |
| LOP_INSERT_ROWS         | LCX_CLUSTERED           | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |         23544 |     218 |
| LOP_INSERT_ROWS         | LCX_HEAP                | dbo.#719CDDE7                                |            72 |       1 |
| LOP_INSERT_ROWS         | LCX_INDEX_INTERIOR      | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |       1042776 |   10302 |
| LOP_MODIFY_HEADER       | LCX_BULK_OPERATION_PAGE | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |        780216 |   10266 |
| LOP_MODIFY_HEADER       | LCX_HEAP                | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |       1718472 |   20458 |
| LOP_MODIFY_HEADER       | LCX_INDEX_INTERIOR      | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |          3192 |      38 |
| LOP_MODIFY_ROW          | LCX_IAM                 | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |           704 |       8 |
| LOP_MODIFY_ROW          | LCX_PFS                 | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |        114832 |    1307 |
| LOP_MODIFY_ROW          | LCX_PFS                 | Unknown Alloc Unit                           |        231696 |    2633 |
| LOP_RANGE_INSERT        | LCX_NULL                | NULL                                         |            48 |       1 |
| LOP_SET_BITS            | LCX_GAM                 | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |         77100 |    1285 |
| LOP_SET_BITS            | LCX_GAM                 | Unknown Alloc Unit                           |        157920 |    2632 |
| LOP_SET_BITS            | LCX_IAM                 | dbo.#6DCC4D03.PK__#6DCC4D0__3213E83F6FB49575 |         77100 |    1285 |
| LOP_SET_BITS            | LCX_IAM                 | Unknown Alloc Unit                           |        157920 |    2632 |
| LOP_XACT_CKPT           | LCX_NULL                | NULL                                         |            92 |       1 |
| Total                   | NULL                    | NULL                                         |     108102960 | 2602218 |
+-------------------------+-------------------------+----------------------------------------------+---------------+---------+
— मार्टिन स्मिथ
स्रोत
विस्तृत पुष्टि के लिए धन्यवाद। तो यह सवाल अभी भी है कि DELETE आपके कार्यकाल का उपयोग करते हुए तालिका को वास्तव में खाली क्यों नहीं लौटा रहा है । इसके अलावा, यह #temp तालिकाओं का उपयोग करने के लिए तर्क देगा यदि बैच प्रसंस्करण लूप में स्पष्ट / आबादी का उपयोग किया जाता है।
— 孔夫子
1
@RichardTheKiwi - अपने दम पर TRUNCATEओवर का लाभ DELETEभी उस के लिए तर्क होगा। मैं बड़ी संख्या में पंक्तियों के लिए तालिका चर पर शायद ही कभी विचार करूंगा।
— मार्टिन स्मिथ
यह आलसी लगेगा, लेकिन एक बैच में 1000 बार डालने पर 1 से 10-रिकॉर्ड (चर) दोहराए जाने के समान लक्षण नहीं दिखेंगे? बड़ी संख्या में पंक्तियों का उपयोग केवल समस्या को बढ़ाता है, और अंतर को बेहतर देखने के लिए पैमाने प्रदान करता है। प्रश्न का सार यह साबित करना है कि एक या दूसरा तरीका यह है कि # टेबल टेम्प्लेट बेहतर होंगे, एक बार हम जानते हैं कि अंतर क्या है।
— 12:51
वैसे मेरा सिद्धांत यह है कि यह उन 10,000+पृष्ठों का आवंटन है जो बहुत अधिक अनुकूलित तरीके से होता है और लगता है कि प्रति पृष्ठ ओवरहेड से कुछ बचा जा सकता है। छोटे आवेषण के लिए मैं किसी भी ऐसे अंतर को कम महत्वपूर्ण होने की उम्मीद करूंगा।
— मार्टिन स्मिथ
@ रिचर्ड_किवी - धन्यवाद! इस पर शायद कुछ और कहना है। जैसा कि मैंने एसक्यूएल कीवी के समान संस्करण में अपग्रेड करने की कोशिश की है और अगर मुझे अभी भी अलग-अलग कोड पथ दिखाई देते हैं। यदि ऐसा है तो शायद यह हार्डवेयर पर निर्भर है कि यह इतना अंतर करता है (मेरे परीक्षण मेरे डेस्कटॉप पीसी पर सभी डेटा और एक ही SSD पर लॉग फ़ाइलों के साथ हुए हैं)
— मार्टिन स्मिथ
0

अवलोकन और अटकलें। । ।

कुछ प्रणालियों पर, CURRENT_TIMESTAMP को वर्तमान लेनदेन की शुरुआत के समय के रूप में परिभाषित किया गया है। CURRENT_TIMESTAMP SQL सर्वर पर कैसे व्यवहार करता है, इसकी एक त्वरित खोज ने कोई निश्चित दस्तावेजीकरण नहीं किया। लेकिन SQL सर्वर का डिफॉल्ट मोड ऑटोकॉमिट ट्रांजेक्शन के लिए है, और यहाँ कोई BEGIN TRANSACTION नहीं है, इसलिए यह चाहिए INSERT स्टेटमेंट से ठीक पहले का समय । (DELETE स्टेटमेंट स्वचालित रूप से कमिट होना चाहिए, और CURRENT_TIMESTAMP SQL सर्वर पर काम करने का तरीका जो भी हो, यह आपके द्वारा स्वचालित रूप से प्रतिबद्ध लेनदेन का उपयोग करते समय DELETE स्टेटमेंट के साथ कुछ भी नहीं होना चाहिए।)

पहली पुनरावृत्ति पर, DELETE कथन के पास करने के लिए कोई वास्तविक कार्य नहीं है, और लॉग करने के लिए कोई व्यक्तिगत पंक्तियाँ नहीं हैं। हो सकता है कि ऑप्टिमाइज़र को पता हो कि, और वह पहली यात्रा के लिए समय कम कर रहा है। (हटाने के लिए कोई पंक्तियों का संयोजन, और लॉग करने के लिए कोई व्यक्तिगत पंक्तियाँ नहीं।)

आप (मुझे लगता है) को हटाने से पहले सम्मिलित करके परीक्षण कर सकते हैं।

— माइक शेरिल 'कैट रिकॉल'
स्रोत
मैं आज सवालों के जवाब देना बंद करने जा रहा हूं। या जो कुछ भी मैं कर रहा हूं जब मैं उस बॉक्स में चीजें टाइप करता हूं।
— माइक शेरिल 'कैट रिकॉल'
क्या इस उत्तर को अप्रचलित, स्पर्शरेखा और विचलित करने वाले के रूप में हटा दिया जाना चाहिए?
— ।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.