টাইমস্ট্যাম্পগুলির একটি ব্যাপ্তিতে (দুটি কলাম) কোয়েরি অনুকূলকরণ করা হচ্ছে

Question

আমি উবুন্টু 12.04 এ পোস্টগ্রিজ এসকিউএল 9.1 ব্যবহার করি।

আমাকে অনেক সময়ের মধ্যে রেকর্ড নির্বাচন করতে হবে: আমার টেবিলে time_limitsদুটি timestampক্ষেত্র এবং একটি integerসম্পত্তি রয়েছে। আমার আসল টেবিলের অতিরিক্ত কলাম রয়েছে যা এই প্রশ্নের সাথে জড়িত নয়।

create table (
   start_date_time timestamp,
   end_date_time timestamp, 
   id_phi integer, 
   primary key(start_date_time, end_date_time,id_phi);

এই টেবিলটিতে মোটামুটি 2M রেকর্ড রয়েছে।

নিম্নলিখিতগুলির মতো প্রশ্নগুলি প্রচুর পরিমাণে সময় নিয়েছিল:

select * from time_limits as t 
where t.id_phi=0 
and t.start_date_time <= timestamp'2010-08-08 00:00:00'
and t.end_date_time   >= timestamp'2010-08-08 00:05:00';

সুতরাং আমি অন্য সূচক যুক্ত করার চেষ্টা করেছি - পিকে বিপরীত:

create index idx_inversed on time_limits(id_phi, start_date_time, end_date_time);

পারফরম্যান্সের উন্নতি হয়েছে এমন ধারণাটি আমি পেয়েছি: টেবিলের মাঝখানে রেকর্ডগুলি অ্যাক্সেস করার সময়টি আরও যুক্তিসঙ্গত বলে মনে হচ্ছে: কোথাও 40 এবং 90 সেকেন্ডের মধ্যে।

তবে সময় সীমার মধ্যবর্তী মানের জন্য এটি এখনও কয়েক দশক সেকেন্ড। এবং টেবিলের শেষটিকে লক্ষ্য করে যখন আরও দ্বিগুণ হন (কালানুক্রমিকভাবে বলতে হয়)।

আমি explain analyzeএই ক্যোয়ারী পরিকল্পনাটি পাওয়ার জন্য প্রথমবার চেষ্টা করেছি :

 Bitmap Heap Scan on time_limits  (cost=4730.38..22465.32 rows=62682 width=36) (actual time=44.446..44.446 rows=0 loops=1)
   Recheck Cond: ((id_phi = 0) AND (start_date_time <= '2011-08-08 00:00:00'::timestamp without time zone) AND (end_date_time >= '2011-08-08 00:05:00'::timestamp without time zone))
   ->  Bitmap Index Scan on idx_time_limits_phi_start_end  (cost=0.00..4714.71 rows=62682 width=0) (actual time=44.437..44.437 rows=0 loops=1)
         Index Cond: ((id_phi = 0) AND (start_date_time <= '2011-08-08 00:00:00'::timestamp without time zone) AND (end_date_time >= '2011-08-08 00:05:00'::timestamp without time zone))
 Total runtime: 44.507 ms

Depesz.com এ ফলাফল দেখুন।

অনুসন্ধানটি অনুকূল করতে আমি কী করতে পারি? আপনি একবারে id_phiসেট হয়ে থাকা দুটি টাইমস্ট্যাম্প কলামগুলি স্ক্যান করতে সমস্ত সময় ব্যয় করতে পারেন 0। এবং টাইমস্ট্যাম্পগুলিতে আমি বড় স্ক্যান (60 কে সারি!) বুঝতে পারি না। এগুলি কি প্রাথমিক কী দ্বারা সূচিযুক্ত নয় এবং idx_inversedআমি যুক্ত করেছি?

আমার কি টাইমস্ট্যাম্পের ধরণ থেকে অন্য কিছুতে পরিবর্তন করা উচিত?

আমি জিআইএসটি এবং জিআইএন সূচী সম্পর্কে কিছুটা পড়েছি। আমি সংগ্রহ করি তারা কাস্টম ধরণের জন্য কিছু শর্তে আরও দক্ষ হতে পারে। এটি কি আমার ব্যবহারের ক্ষেত্রে ব্যবহারযোগ্য বিকল্প?

Comments

ভাল এটি 45s। আমি জানি না কেন এটি 45 মিমি বলে। 45 মিমি তত দ্রুত হলে আমি অভিযোগও শুরু করতাম না ... :-) সম্ভবত বিশ্লেষণের ব্যাখ্যাটিতে কোনও বাগ থাকতে পারে। অথবা সম্ভবত এটি সম্পাদন করার বিশ্লেষণের সময়। জানিনা। তবে 40/50 সেকেন্ড আমি যা পরিমাপ করি।

— স্টিফেন রোল্যান্ড

explain analyzeআউটপুটে রিপোর্ট করা সময়টি সার্ভারে কোয়েরির প্রয়োজনীয় সময় । যদি আপনার ক্যোয়ারীতে 45 ​​সেকেন্ড সময় লাগে, তবে অতিরিক্ত সময় ব্যয় করা হয়েছে ডাটাবেস থেকে ডেটা স্থানান্তরিত প্রোগ্রামটিতে কোয়েরিটি চালানো সর্বোপরি এটি 62682 সারি এবং যদি প্রতিটি সারি বড় হয় (যেমন দীর্ঘ varcharবা textকলাম রয়েছে) তবে এটি স্থানান্তর সময়কে প্রভাবিত করতে পারে আয়তন বহুলাংশে।

— a_horse_with_no_name

@ এ_হর্স_বিহীন_নো নাম: rows=62682 rowsহ'ল পরিকল্পনাকারীর অনুমান । ক্যোয়ারী 0 টি সারি দেয়। (actual time=44.446..44.446 rows=0 loops=1)

— এরউইন ব্র্যান্ডসটেটার

@ এরউইন ব্র্যান্ডসটেটার: আহ, ঠিক আছে। আমি তা উপেক্ষা করেছি। কিন্তু তবুও আমি মৃত্যুদন্ড কার্যকর করার সময় সম্পর্কে মিথ্যা বিশ্লেষণের ব্যাখ্যাটি আউটপুটটি কখনও দেখিনি।

— a_horse_with_no_name

Answer 1

পোস্টগ্রিস 9.1 বা তার পরে:

CREATE INDEX idx_time_limits_ts_inverse
ON time_limits (id_phi, start_date_time, end_date_time DESC);

বেশিরভাগ ক্ষেত্রে একটি সূচীর সাজানোর ক্রমটি খুব কমই প্রাসঙ্গিক। পোস্টগ্রিসগুলি কার্যত দ্রুত হিসাবে পিছন দিকে স্ক্যান করতে পারে। তবে একাধিক কলামে পরিসীমা প্রশ্নের জন্য এটি একটি বিশাল পার্থক্য করতে পারে । ঘনিষ্ঠভাবে সম্পর্কিত:

• পোস্টগ্রিএসকিউএল সূচকটি রেঞ্জের ক্যোয়ারির জন্য ব্যবহৃত হয় না

আপনার জিজ্ঞাসা বিবেচনা করুন:

SELECT *
FROM   time_limits
WHERE  id_phi = 0
AND    start_date_time <= '2010-08-08 00:00'
AND    end_date_time   >= '2010-08-08 00:05';

id_phiসূচকে প্রথম কলামের সাজানোর ক্রম অপ্রাসঙ্গিক। যেহেতু এটি সাম্যের জন্য পরীক্ষা করা হয়েছে ( =), এটি প্রথমে আসা উচিত। আপনি ঠিক আছে। এই সম্পর্কিত উত্তরে আরও:

• মাল্টিকোলোম সূচক এবং কর্মক্ষমতা

পোস্টগ্রাগিরা আর id_phi = 0কোনও সময় পরের দিকে যেতে পারে এবং মিলে যাওয়া সূচকের নিম্নলিখিত দুটি কলাম বিবেচনা করতে পারে। এগুলি উল্টানো বাছাইয়ের ক্রম ( <=, >=) এর সীমার শর্তগুলির সাথে অনুসন্ধান করা হয় । আমার সূচীতে, যোগ্যতা সারিগুলি প্রথম আসে। একটি বি-ট্রি সূচী ¹ দিয়ে দ্রুততম উপায় হওয়া উচিত :

• আপনি চান start_date_time <= something: সূচকের প্রথমতম টাইমস্ট্যাম্প রয়েছে।
  • এটি যদি
    যোগ্যতা অর্জন করে তবে কলাম 3 পরীক্ষা করে দেখুন row
• আপনি চান end_date_time >= something: সূচীতে সর্বশেষতম টাইমস্ট্যাম্প রয়েছে।
  • যদি এটি যোগ্য হয় তবে প্রথমটি না হওয়া অবধি সারিগুলি আনতে থাকুন (সুপার দ্রুত)।
    কলাম 2 এর পরবর্তী মান সহ চালিয়ে যান ..

পোস্টগ্র্যাগগুলি হয় সামনের দিকে বা পিছনে স্ক্যান করতে পারে । আপনার সূচকটি যেভাবে ছিল, এটি প্রথম দুটি কলামের সাথে মিলিয়ে সমস্ত সারি পড়তে হবে এবং তারপরে তৃতীয়টিতে ফিল্টার করতে হবে। অনুচ্ছেদ সূচী এবংORDER BY ম্যানুয়ালটিতে অবশ্যই নিশ্চিত হন । এটি আপনার প্রশ্নটি বেশ ভাল ফিট করে।

প্রথম দুটি কলামে কয়টি সারি মিলছে? সারণির সময়সীমা শুরুর
খুব start_date_timeকাছাকাছি মাত্র কয়েক জন । তবে প্রায় সমস্ত সারি id_phi = 0টেবিলে কালানুক্রমিক প্রান্তে! সুতরাং পরবর্তী সময়ের সাথে পারফরম্যান্স খারাপ হয়।

পরিকল্পনাকারী অনুমান

পরিকল্পনাকারী rows=62682আপনার উদাহরণ ক্যোয়ারির জন্য অনুমান করে । এর মধ্যে কেউ যোগ্যতা অর্জন করে না ( rows=0)। আপনি যদি সারণির জন্য পরিসংখ্যানের টার্গেট বাড়িয়ে দেন তবে আপনি আরও ভাল অনুমান পেতে পারেন। 2.000.000 সারি জন্য ...

ALTER TABLE time_limits ALTER start_date_time SET STATISTICS 1000;
ALTER TABLE time_limits ALTER end_date_time   SET STATISTICS 1000;

... দিতে পারে। বা আরও উচ্চতর। এই সম্পর্কিত উত্তরে আরও:

• PostgreSQL এ পরিসংখ্যান লক্ষ্যগুলি পরীক্ষা করুন

আমি অনুমান করি আপনার এটির জন্য id_phi(কেবলমাত্র কয়েকটি স্বতন্ত্র মান সমানভাবে বিতরণ করা) দরকার নেই, তবে টাইমস্ট্যাম্পগুলির জন্য (প্রচুর স্বতন্ত্র মান, অসমভাবে বিতরণ করা হয়েছে)।
উন্নত সূচকের সাথে এটি খুব বেশি গুরুত্বপূর্ণ বলে আমি মনে করি না।

CLUSTER / pg_repack

আপনি যদি এটি দ্রুত চান তবে এখনও, আপনি আপনার টেবিলের সারিগুলির দৈহিক ক্রমটি প্রবাহিত করতে পারেন। আপনি যদি নিজের টেবিলটি স্বতন্ত্রভাবে অল্প সময়ের জন্য লক করে রাখতে পারেন তবে (উদাহরণস্বরূপ বন্ধের সময়) আপনার টেবিলটি পুনরায় লেখতে এবং সূচি অনুসারে সারিগুলি অর্ডার করতে:

ALTER TABLE time_limits CLUSTER ON idx_time_limits_inversed;

একযোগে অ্যাক্সেসের সাথে, pg_repack বিবেচনা করুন , যা একচেটিয়া লক ছাড়াই এটি করতে পারে।

যেভাবেই হোক না কেন, প্রভাবটি হ'ল টেবিল থেকে কম ব্লকগুলি পড়তে হবে এবং সমস্ত কিছু পূর্বনির্ধারিত। এটি টেবিলে দৈহিক বাছাইয়ের ক্রমকে টুকরো টুকরো করে লেখার সাথে সময়ের সাথে এক সময়কার প্রভাবের অবনতি ঘটে।

পোস্টগ্রিস 9.2+ এ জিআইএসটি সূচক

¹ পিজি 9.2+ সহ আরও একটি, সম্ভবত দ্রুত বিকল্প রয়েছে: একটি পরিসীমা কলামের জন্য একটি জিআইএসটি সূচক।

• সেখানে বিল্ট-ইন জন্য পরিসীমা ধরনের timestampএবং timestamp with time zone: tsrange,tstzrange । একটি অতিরিক্ত integerকলামের মতো একটি বিটি্রি সূচক সাধারণত দ্রুত হয় id_phi। ছোট এবং বজায় রাখার জন্যও সস্তা। তবে ক্যোয়ারী সম্ভবত এখনও সম্মিলিত সূচকের সাথে সামগ্রিকভাবে দ্রুত হবে।

• আপনার টেবিল সংজ্ঞা পরিবর্তন করুন বা একটি এক্সপ্রেশন সূচক ব্যবহার করুন ।

• মাল্টিকালমাম জিআইএসটি সূচকের জন্য আপনাকে অতিরিক্ত মডিউল btree_gistইনস্টল করতে হবে (প্রতি ডাটাবেস একবার) যা অন্তর্ভুক্ত করতে অপারেটর ক্লাস সরবরাহ করে integer।

ত্রিফেক্টটা! একটি মাল্টিকালম ফাংশনাল জিআইএসটি সূচক :

CREATE EXTENSION IF NOT EXISTS btree_gist;  -- if not installed, yet

CREATE INDEX idx_time_limits_funky ON time_limits USING gist
(id_phi, tsrange(start_date_time, end_date_time, '[]'));

আপনার ক্যোয়ারীতে এখন "অন্তর্ভুক্ত ব্যাপ্তি" অপারেটরটি@> ব্যবহার করুন :

SELECT *
FROM   time_limits
WHERE  id_phi = 0
AND    tsrange(start_date_time, end_date_time, '[]')
    @> tsrange('2010-08-08 00:00', '2010-08-08 00:05', '[]')

পোস্টগ্রিস 9.3+ এ এসপি-জিএসটি সূচক

একটি এস পি-সারকথা সূচক ক্যোয়ারী এই ধরনের আরও দ্রুত হতে পারে - ব্যতীত , যে ম্যানুয়াল উদ্ধৃত :

বর্তমানে কেবল বি-ট্রি, জিএসটি, জিআইএন এবং ব্রিন সূচক প্রকারগুলি মাল্টিকালম ইনডেক্সগুলিকে সমর্থন করে।

পোস্টগ্র্রেস ১২-তে এখনও সত্য।
আপনাকে spgistকেবলমাত্র (tsrange(...))দ্বিতীয় btreeসূচকের সাথে একটি সূচক একত্রিত করতে হবে (id_phi)। অতিরিক্ত ওভারহেড যুক্ত করে আমি নিশ্চিত যে এটি প্রতিযোগিতা করতে পারে।
মাত্র একটি tsrangeকলামের জন্য একটি মানদণ্ডের সাথে সম্পর্কিত উত্তর :

• পোস্টগ্র্রেএসকিউএলে এই অপারেশন কোয়েরিটি ঘন্টা করুন

Comments

আমার এটি কমপক্ষে একবারই বলা উচিত, আপনার এসও এবং ডিবিএর প্রতিটি উত্তর সত্যই উচ্চতর সংযোজনযুক্ত মান / এক্সপ্রেরটিস এবং বেশিরভাগ সময় সবচেয়ে সম্পূর্ণ। শুধু একবার বলার জন্য: শ্রদ্ধা !.

— স্টিফেন রোল্যান্ড

মেরকি বিয়েন! :) তাহলে আপনি কি দ্রুত ফলাফল পেয়েছেন?

— এরউইন ব্র্যান্ডসটেটার

আমার নিবিড় বিশ্রী জিজ্ঞাসা থেকে উত্পন্ন বড় বালক অনুলিপিটি শেষ করতে হবে, সুতরাং প্রক্রিয়াটি সত্যই ধীর করে তুলছে, প্রশ্নটি জিজ্ঞাসা করার কয়েক ঘন্টা আগে এটি ঘুরে দাঁড়িয়েছিল। তবে আমি গণনা করেছি, এবং আমি সিদ্ধান্ত নিয়েছি যে এটিকে টমরো সকাল অবধি ঘুরিয়ে দেওয়া হবে, এটি শেষ হবে এবং নতুন টেবিলটি টমোরোতে ভরাট হওয়ার জন্য প্রস্তুত। কাজের সময় আমি আপনার সূচকগুলি একই সাথে তৈরি করার চেষ্টা করেছি, তবে খুব বেশি অ্যাক্সেসের কারণে (আমার মনে হয়), সূচি তৈরির বিষয়টি লক করা উচিত। আমি আবার একই পরীক্ষার সময়টিকে পুনরায় করব আপনার সমাধান দিয়ে। ডেবিয়ান / উবুন্টুর জন্য কীভাবে 9.2 ;-) এ আপগ্রেড করা হয়েছে তাও আমি দেখেছি।

— স্টিফেন রোল্যান্ড

@ স্টাফেনরোল্যান্ড: আপনি এখনও কোয়েরিকে ৪০ সেকেন্ডের বেশি সময় নিচ্ছেন এমনটি কেন বিশ্লেষণ বিশ্লেষণ করে ৪৫ মিলি সেকেন্ড দেখায় তা আকর্ষণীয় হবে।

— a_horse_with_no_name

@ জন: পোস্টগ্রিস সূচকগুলি এগিয়ে বা পিছনের দিকে যেতে পারে তবে এটি একই স্ক্যানে দিক পরিবর্তন করতে পারে না। আদর্শভাবে, আপনার কাছে নোডের জন্য প্রথমে (বা শেষ) সমস্ত যোগ্যতার সারি রয়েছে, তবে সর্বোত্তম ফলাফল পাওয়ার জন্য এটি সমস্ত কলামের জন্য একই প্রান্তিককরণ (ম্যাচের ক্যোয়ারী পূর্বাভাসগুলি) হতে হবে।

— এরউইন ব্র্যান্ডসটেটার

Answer 2

এরউইনের উত্তর ইতিমধ্যে ব্যাপক, তবে:

টাইমস্ট্যাম্পগুলির জন্য রেঞ্জের ধরণগুলি জেফ ডেভিসের কাছ থেকে টেম্পোরাল এক্সটেনশনের সাথে পোস্টগ্রাইএসকিউএল 9.1 এ উপলব্ধ: https://github.com/jeff-davis/ পোষ্টগ্রিএসকিউএল- টেম্পোরাল

দ্রষ্টব্য: সীমিত বৈশিষ্ট্য রয়েছে (টাইমস্ট্যাম্প্টজ ব্যবহার করে এবং আপনার কেবল '[)' শৈলীর ওভারল্যাপ আফিক থাকতে পারে)। এছাড়াও, পোস্টগ্রেএসকিউএল 9.2 এ আপগ্রেড করার আরও অনেক দুর্দান্ত কারণ রয়েছে।

Answer 3

আপনি একটি পৃথক ক্রমে মাল্টিকালম ইনডেক্স তৈরি করার চেষ্টা করতে পারেন:

primary key(id_phi, start_date_time,end_date_time);

আমি একবার একটি অনুরূপ পোস্ট প্রশ্ন একটি multicolumn সূচির উপর ইনডেক্স ক্রম এর সাথে সম্পর্কিত। কীটি অনুসন্ধানের স্থানটি হ্রাস করতে প্রথমে সবচেয়ে সীমাবদ্ধ শর্ত ব্যবহার করার চেষ্টা করছে।

সম্পাদনা : আমার ভুল এখন আমি দেখতে পাচ্ছি যে আপনি ইতিমধ্যে এই সূচকটি সংজ্ঞায়িত করেছেন।

Comments

আমি ইতিমধ্যে উভয় সূচক আছে। প্রাথমিক কী বাদে অন্যটি, তবে আপনার প্রস্তাবিত সূচকটি ইতিমধ্যে বিদ্যমান এবং আপনি যদি ব্যাখ্যাটির দিকে তাকান তবে এটি ব্যবহৃত হয়:Bitmap Index Scan on idx_time_limits_phi_start_end

— স্টিফেন রোল্যান্ড

Answer 4

আমি দ্রুত বৃদ্ধি করতে পরিচালিত (1 সেকেন্ড থেকে 70 মিমি)

আমার কাছে অনেকগুলি পরিমাপের সমাহার এবং অনেকগুলি স্তরের ( lকলাম) (30 সে, 1 মি, 1 ঘন্টা, ইত্যাদি) সহ একটি টেবিল রয়েছে যেখানে দুটি পরিসীমা আবদ্ধ কলাম রয়েছে: $sশুরু এবং $eশেষের জন্য।

আমি দুটি মাল্টিকালম ইনডেক্স তৈরি করেছি: একটি শুরুতে এবং শেষের জন্য একটি।

আমি নির্বাচন করা ক্যোয়ারী সামঞ্জস্য করেছি: রেঞ্জগুলি নির্বাচন করুন যেখানে তাদের প্রারম্ভিক সীমাটি পরিসীমাতে রয়েছে। অতিরিক্তভাবে রেঞ্জগুলি নির্বাচন করুন যেখানে তাদের শেষ সীমাটি প্রদত্ত পরিসীমাতে রয়েছে।

দক্ষতার সাথে আমাদের সূচকগুলি ব্যবহার করে সারিগুলির দুটি স্ট্রিম ব্যাখ্যা করুন।

ইনডেক্সে:

drop index if exists agg_search_a;
CREATE INDEX agg_search_a
ON agg (measurement_id, l, "$s");

drop index if exists agg_search_b;
CREATE INDEX agg_search_b
ON agg (measurement_id, l, "$e");

কোয়েরি নির্বাচন করুন:

select "$s", "$e", a, t, b, c from agg
where 
    measurement_id=0 
    and l =  '30s'
    and (
        (
            "$s" > '2013-05-01 02:05:05'
            and "$s" < '2013-05-01 02:18:15'
        )
        or 
        (
             "$e" > '2013-05-01 02:00:05'
            and "$e" < '2013-05-01 02:18:05'
        )
    )

;

ব্যাখ্যা করা:

[
  {
    "Execution Time": 0.058,
    "Planning Time": 0.112,
    "Plan": {
      "Startup Cost": 10.18,
      "Rows Removed by Index Recheck": 0,
      "Actual Rows": 37,
      "Plans": [
    {
      "Startup Cost": 10.18,
      "Actual Rows": 0,
      "Plans": [
        {
          "Startup Cost": 0,
          "Plan Width": 0,
          "Actual Rows": 26,
          "Node Type": "Bitmap Index Scan",
          "Index Cond": "((measurement_id = 0) AND ((l)::text = '30s'::text) AND (\"$s\" > '2013-05-01 02:05:05'::timestamp without time zone) AND (\"$s\" < '2013-05-01 02:18:15'::timestamp without time zone))",
          "Plan Rows": 29,
          "Parallel Aware": false,
          "Actual Total Time": 0.016,
          "Parent Relationship": "Member",
          "Actual Startup Time": 0.016,
          "Total Cost": 5,
          "Actual Loops": 1,
          "Index Name": "agg_search_a"
        },
        {
          "Startup Cost": 0,
          "Plan Width": 0,
          "Actual Rows": 36,
          "Node Type": "Bitmap Index Scan",
          "Index Cond": "((measurement_id = 0) AND ((l)::text = '30s'::text) AND (\"$e\" > '2013-05-01 02:00:05'::timestamp without time zone) AND (\"$e\" < '2013-05-01 02:18:05'::timestamp without time zone))",
          "Plan Rows": 39,
          "Parallel Aware": false,
          "Actual Total Time": 0.011,
          "Parent Relationship": "Member",
          "Actual Startup Time": 0.011,
          "Total Cost": 5.15,
          "Actual Loops": 1,
          "Index Name": "agg_search_b"
        }
      ],
      "Node Type": "BitmapOr",
      "Plan Rows": 68,
      "Parallel Aware": false,
      "Actual Total Time": 0.027,
      "Parent Relationship": "Outer",
      "Actual Startup Time": 0.027,
      "Plan Width": 0,
      "Actual Loops": 1,
      "Total Cost": 10.18
    }
      ],
      "Exact Heap Blocks": 1,
      "Node Type": "Bitmap Heap Scan",
      "Plan Rows": 68,
      "Relation Name": "agg",
      "Alias": "agg",
      "Parallel Aware": false,
      "Actual Total Time": 0.037,
      "Recheck Cond": "(((measurement_id = 0) AND ((l)::text = '30s'::text) AND (\"$s\" > '2013-05-01 02:05:05'::timestamp without time zone) AND (\"$s\" < '2013-05-01 02:18:15'::timestamp without time zone)) OR ((measurement_id = 0) AND ((l)::text = '30s'::text) AND (\"$e\" > '2013-05-01 02:00:05'::timestamp without time zone) AND (\"$e\" < '2013-05-01 02:18:05'::timestamp without time zone)))",
      "Lossy Heap Blocks": 0,
      "Actual Startup Time": 0.033,
      "Plan Width": 44,
      "Actual Loops": 1,
      "Total Cost": 280.95
    },
    "Triggers": []
  }
]

কৌশলটি হ'ল আপনার পরিকল্পনার নোডগুলিতে কেবল সচ্ছল সারি রয়েছে। পূর্বে আমরা প্ল্যান নোডে কয়েক হাজার সারি পেয়েছিলাম কারণ এটি নির্বাচন করা হয়েছে all points from some point in time to the very end, তারপরে নোডটি অনাদায়ী সারিগুলি সরিয়ে ফেলে।