Pg_buffercache দিয়ে কিছুটা খেলে আমি আপনার কয়েকটি প্রশ্নের উত্তর পেতে পারি।
- এটি বেশ সুস্পষ্ট, তবে (5) এর ফলাফলগুলিও হ'ল উত্তরটি হ্যাঁ
- আমি এটির জন্য এখনও একটি ভাল উদাহরণ স্থাপন করতে পারি না, আপাতত এটি হ্যাঁ না-এর চেয়ে বেশি :) (নীচে আমার সম্পাদনা দেখুন, উত্তরটি নেই ))
- যেহেতু পরিকল্পনাকারী হ'ল কে সিদ্ধান্ত নেন যে কোনও সূচক ব্যবহার করবেন কিনা, তাই আমরা হ্যাঁ বলতে পারি , এটি ক্যাশেিংয়ের সিদ্ধান্ত নেয় (তবে এটি আরও জটিল)
- ক্যাশিংয়ের সঠিক বিবরণ উত্স কোড থেকে নেওয়া যেতে পারে, আমি এই বিষয় ছাড়া খুব বেশি এই বিষয়টিতে খুঁজে পাইনি এই এক (লেখক দেখি উত্তর খুব)। যাইহোক, আমি নিশ্চিত যে এটি আবার সাধারণ হ্যাঁ বা না এর চেয়ে অনেক জটিল। (আবারও, আমার সম্পাদনা থেকে আপনি কিছু ধারণা পেতে পারেন - যেহেতু ক্যাশের আকার সীমাবদ্ধ, সেই 'বুদ্ধিমান' সূচীগুলি উপলব্ধ জায়গার জন্য প্রতিযোগিতা করে they যদি তারা খুব বেশি হয় তবে তারা একে অপরকে ক্যাশে থেকে লাথি মারবে - সুতরাং উত্তরটি বরং হয় না । )
pg_buffercacheশো সহ একটি সহজ ক্যোয়ারী হিসাবে , উত্তর একটি নির্দিষ্ট YES । এটি লক্ষণীয় যে অস্থায়ী সারণী ডেটা এখানে ক্যাশে হবে না ।
সম্পাদনা
আমি টেবিল এবং সূচক স্টোরেজ সম্পর্কে জেরেমিয়া পেশকার ভয়ঙ্কর নিবন্ধটি পেয়েছি । সেখান থেকে তথ্য দিয়ে, আমি উত্তর দিতে পারে (2) । আমি একটি ছোট পরীক্ষা সেট আপ করেছি, যাতে আপনি নিজেরাই এটি পরীক্ষা করতে পারেন।
-- we will need two extensions
CREATE EXTENSION pg_buffercache;
CREATE EXTENSION pageinspect;
-- a very simple test table
CREATE TABLE index_cache_test (
id serial
, blah text
);
-- I am a bit megalomaniac here, but I will use this for other purposes as well
INSERT INTO index_cache_test
SELECT i, i::text || 'a'
FROM generate_series(1, 1000000) a(i);
-- let's create the index to be cached
CREATE INDEX idx_cache_test ON index_cache_test (id);
-- now we can have a look at what is cached
SELECT c.relname,count(*) AS buffers
FROM
pg_class c
INNER JOIN pg_buffercache b ON b.relfilenode = c.relfilenode
INNER JOIN pg_database d ON (b.reldatabase = d.oid AND d.datname = current_database())
GROUP BY c.relname
ORDER BY 2 DESC LIMIT 10;
relname | buffers
----------------------------------+---------
index_cache_test | 2747
pg_statistic_relid_att_inh_index | 4
pg_operator_oprname_l_r_n_index | 4
... (others are all pg_something, which are not interesting now)
-- this shows that the whole table is cached and our index is not in use yet
-- now we can check which row is where in our index
-- in the ctid column, the first number shows the page, so
-- all rows starting with the same number are stored in the same page
SELECT * FROM bt_page_items('idx_cache_test', 1);
itemoffset | ctid | itemlen | nulls | vars | data
------------+---------+---------+-------+------+-------------------------
1 | (1,164) | 16 | f | f | 6f 01 00 00 00 00 00 00
2 | (0,1) | 16 | f | f | 01 00 00 00 00 00 00 00
3 | (0,2) | 16 | f | f | 02 00 00 00 00 00 00 00
4 | (0,3) | 16 | f | f | 03 00 00 00 00 00 00 00
5 | (0,4) | 16 | f | f | 04 00 00 00 00 00 00 00
6 | (0,5) | 16 | f | f | 05 00 00 00 00 00 00 00
...
64 | (0,63) | 16 | f | f | 3f 00 00 00 00 00 00 00
65 | (0,64) | 16 | f | f | 40 00 00 00 00 00 00 00
-- with the information obtained, we can write a query which is supposed to
-- touch only a single page of the index
EXPLAIN (ANALYZE, BUFFERS)
SELECT id
FROM index_cache_test
WHERE id BETWEEN 10 AND 20 ORDER BY id
;
Index Scan using idx_test_cache on index_cache_test (cost=0.00..8.54 rows=9 width=4) (actual time=0.031..0.042 rows=11 loops=1)
Index Cond: ((id >= 10) AND (id <= 20))
Buffers: shared hit=4
Total runtime: 0.094 ms
(4 rows)
-- let's have a look at the cache again (the query remains the same as above)
relname | buffers
----------------------------------+---------
index_cache_test | 2747
idx_test_cache | 4
...
-- and compare it to a bigger index scan:
EXPLAIN (ANALYZE, BUFFERS)
SELECT id
FROM index_cache_test
WHERE id <= 20000 ORDER BY id
;
Index Scan using idx_test_cache on index_cache_test (cost=0.00..666.43 rows=19490 width=4) (actual time=0.072..19.921 rows=20000 loops=1)
Index Cond: (id <= 20000)
Buffers: shared hit=4 read=162
Total runtime: 24.967 ms
(4 rows)
-- this already shows that something was in the cache and further pages were read from disk
-- but to be sure, a final glance at cache contents:
relname | buffers
----------------------------------+---------
index_cache_test | 2691
idx_test_cache | 58
-- note that some of the table pages are disappeared
-- but, more importantly, a bigger part of our index is now cached
সর্বোপরি, এটি দেখায় যে সূচিপত্র এবং সারণীগুলি পৃষ্ঠায় পৃষ্ঠাতে ক্যাশে করা যেতে পারে, সুতরাং এর উত্তর (2) হয় কোন ।
এবং অস্থায়ী টেবিলগুলি এখানে অ-ক্যাশে করা হয়েছে তা চিত্রিত করার জন্য একটি চূড়ান্ত এক:
CREATE TEMPORARY TABLE tmp_cache_test AS
SELECT * FROM index_cache_test ORDER BY id FETCH FIRST 20000 ROWS ONLY;
EXPLAIN (ANALYZE, BUFFERS) SELECT id FROM tmp_cache_test ORDER BY id;
-- checking the buffer cache now shows no sign of the temp table