টাইমস্ট্যাম্প দ্বারা বিভক্ত টেবিল জড়িত জন্য পার্টিশনের সীমাবদ্ধতা ব্যবহৃত হয় না


11

আমার বিভাজনযুক্ত টেবিল কাঠামো রয়েছে যেমন:

CREATE TABLE measurements (
    sensor_id bigint,
    tx timestamp,
    measurement int
);

CREATE TABLE measurements_201201(
    CHECK (tx >= '2012-01-01 00:00:00'::timestamp without time zone 
       AND tx < ('2012-01-01 00:00:00'::timestamp without time zone + '1 mon'::interval))    
)INHERITS (measurements);
CREATE INDEX ON measurements_201201(sensor_id);
CREATE INDEX ON measurements_201201(tx);
CREATE INDEX ON measurements_201201(sensor_id, tx);
....

ইত্যাদি। প্রতিটি টেবিলে প্রায় 20M সারি থাকে।

আমি যদি সেন্সরগুলির নমুনা WHEREএবং ধারাটিতে টাইমস্ট্যাম্পগুলির নমুনার সন্ধান করি তবে ক্যোয়ারী পরিকল্পনাটি সঠিক সারণীগুলি নির্বাচিত হচ্ছে এবং সূচকগুলি ব্যবহৃত হচ্ছে তা দেখায় যেমন:

SELECT *
FROM measurements
INNER JOIN sensors TABLESAMPLE BERNOULLI (0.01) USING (sensor_id)
WHERE tx BETWEEN '2015-01-04 05:00' AND '2015-01-04 06:00' 
    OR tx BETWEEN '2015-02-04 05:00' AND '2015-02-04 06:00' 
    OR tx BETWEEN '2014-03-05 05:00' AND '2014-04-07 06:00' ;

তবে, আমি যদি কোনও সিটিই ব্যবহার করি, বা টাইমস্ট্যাম্প মানগুলি একটি টেবিলের মধ্যে রাখি (এমনকি অস্থায়ী টেবিলের সূচী সহ দেখানো হয় না)।

WITH sensor_sample AS(
    SELECT sensor_id, start_ts, end_ts
    FROM sensors TABLESAMPLE BERNOULLI (0.01)
    CROSS JOIN (VALUES (TIMESTAMP '2015-01-04 05:00', TIMESTAMP '2015-01-04 06:00'),
        (TIMESTAMP '2015-02-04 05:00', TIMESTAMP '2015-02-04 06:00'),
        (TIMESTAMP  '2014-03-05 05:00', '2014-04-07 06:00') ) tstamps(start_ts, end_ts)
)

নীচের মত কিছু

SET constraint_exclusion = on;
SELECT * FROM measurements
INNER JOIN sensor_sample USING (sensor_id)
WHERE tx BETWEEN start_ts AND end_ts

প্রতিটি টেবিলে একটি সূচক স্ক্যান করে। যা এখনও তুলনামূলকভাবে দ্রুত, তবে ক্রয়ের ক্রমবর্ধমান জটিলতার সাথে এটি সেক স্ক্যানে রূপান্তরিত হতে পারে যা পার্টিশনযুক্ত টেবিলগুলির সীমিত উপসেট (50 এর 4-5) থেকে 40K ডলার সারি পুনরুদ্ধারের জন্য খুব ধীর হয়ে যাবে।

আমি উদ্বিগ্ন যে এই জাতীয় কিছু সমস্যা।

তুচ্ছ তাত্পর্যপূর্ণ প্রকাশের জন্য পোস্টগ্রিসের ক্যোয়ারার পরিকল্পনাকারীকে বুঝতে হবে যে এটি CHECK সীমাবদ্ধতার উপর নির্ভর করতে পারে make অপ্রয়োজনীয় মনে হলেও!

আমার সমস্ত ডেটাতে সেক স্ক্যান চালানোর সম্ভাবনা কমাতে আমি কীভাবে পার্টিশন এবং কোয়েরি কাঠামোর উন্নতি করতে পারি?


1
দুর্দান্ত প্রশ্ন - তবে আপনি যদি এক্সপ্ল্লেইনের ফলাফলগুলি আটকান তবে এটি আরও ভাল হবে (আনালাইজ, বুফার্স)
ফিলিপ্রেম

উত্তর:


1

বাধা-ভিত্তিক বর্জন [সিবিই] কোয়েরি পরিকল্পনার প্রথম পর্যায়ে সম্পাদনা করা হয়, কোয়েরিটি বিশ্লেষণের পরে, প্রকৃত সম্পর্কের ক্ষেত্রে ম্যাপ করা হয়েছে এবং আবার লেখা হয়েছে। ( ইন্টার্নালস , প্ল্যানার / অপ্টিমাইজার স্টেজ)

পরিকল্পনাকারী "সেন্সর_ নমুনা" সারণির কোনও সামগ্রী অনুমান করতে পারবেন না।

সুতরাং আপনি যদি কোয়েরিতে হার্ডকোডযুক্ত মান না রেখে থাকেন তবে পরিকল্পনাকারী "পার্টিশনগুলি" বাদ দেবেন না।

আমার ধারণা, সিটিই ভেরিয়েন্টের সাথে কী ঘটে ... পরিকল্পনাকারী সীমাবদ্ধ কারণ আপনি টেবিলস্যাম্পল ব্যবহার করেন এবং সাবকিউরিয়ায় আক্ষরিক স্থির থাকলেও পুরো সাবকিউরিটি অস্থির হিসাবে বিবেচিত হতে পারে। ( এটি কেবল আমার অনুমান, আমি পরিকল্পনাকারী কোডে বিশেষজ্ঞ নই )

উজ্জ্বল দিক থেকে, নেতিবাচক ফলাফল সহ সূচক স্ক্যানটি অত্যন্ত দ্রুতগতির। (সর্বাধিক একক পৃষ্ঠাগুলি স্ক্যান করুন!) সুতরাং আপনার যদি 10000 পার্টিশন না থাকে, আমি বিরক্ত করব না।

সুতরাং, সরাসরি আপনার প্রশ্নের উত্তর দিতে:

  • আপনি এই ডেটা কাঠামো আরও বেশি উন্নত করতে পারবেন না।

  • রেগার্ডিন সূচক স্ক্যান - তারা সস্তা;

  • ক্রমক্রমিক স্ক্যানগুলি সম্পর্কে - আপনার নিজের উদাহরণে যেমন দেখা যায় তখন এগুলি এড়ানো সম্ভব হয়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.