পোস্টগ্রিসএসকিউএল এর জিইকিউ (জেনেটিক কোয়েরি অপটিমাইজেশন) এ পরিবর্তন


16

আমার পোস্টগ্রিজএসকিউএল এর GEQO কার্যকারিতার সাথে সামঞ্জস্যপূর্ণ কোনও কার্যকারিতা বাস্তবায়ন করতে হবে। আমি বুঝতে পারি যে GEQO পদ্ধতির হল কোয়েরি প্ল্যানগুলিকে পূর্ণসংখ্যার স্ট্রিং হিসাবে এনকোড করা এবং GEQO এলোমেলোভাবে এই সম্ভাব্য যোগদানের ক্রমগুলি তৈরি করে। সূত্র: http://www.postgresql.org/docs/9.3/static/geqo-pg-intro.html

আমার প্রশ্ন: GEQO ফাংশনটি কীভাবে পরিবর্তন করতে হবে যদি আমি সঠিকভাবে যোগ সিকোয়েন্সটি নিশ্চিতভাবে জানি তবে আমাকে আলাদা আলাদা যোগ ক্রমগুলি অনুসন্ধান করতে হবে না। উদাহরণস্বরূপ, যদি আমি জানতাম যে 4 টি সম্পর্কের সাথে যুক্ত হওয়ার সর্বোত্তম উপায়টি 4-1-3-2 হয়, তবে আমাকে অন্য অনুমতিগুলি পরীক্ষা করার দরকার নেই।

জিগ্রিওএসকিউএল কীভাবে জিইকিউও প্রয়োগ করা হয় সে সম্পর্কে কোনও ভাল উপকরণ নেই। পোস্টগ্রিজএসকিউএল কেবল জিইকিউ কার্যকারিতার সামগ্রিক দৃষ্টিভঙ্গি দেয় তবে বেশি ব্যাখ্যা দেয় না।

বা আমি GEQO ব্যবহার না করেই স্ট্যান্ডার্ড_জাইন_সার্চ () নিজেই এই কার্যকারিতাটি অর্জন করতে পারি?


3
দেখে মনে হচ্ছে আপনি কোয়েরি ইঙ্গিতগুলি প্রয়োগ করতে চান। এগুলি সবই ভাল এবং ভাল, তবে পোস্টগ্র্রেএসকিউএল কোরটিতে আপনার এই পরিবর্তনটি গ্রহণের আশা করা উচিত নয় কারণ প্রকল্প সম্প্রদায়টি এমন নয় যা আপনি ক্যোয়ারের ইঙ্গিতগুলির একটি বড় ভক্তকে কল করবেন। আপনি যদি এই সম্পর্কে গুরুতর হন তবে আপনাকে ক্যোয়ার পরিকল্পনাকারী কোডটির বেশ কিছুটা পড়তে হবে এবং আপনাকে কীভাবে পুনরায় লেখক থেকে এবং পরিকল্পনাকারীর মাধ্যমে পার্সার থেকে আপনার ইঙ্গিতগুলি পাস করতে হবে তা নির্ধারণ করতে হবে। আমি এখানে একটি দ্রুত এবং সহজ উত্তর দেখতে পাচ্ছি না। আপনি শেষ পর্যন্ত যা করতে চান তা হ'ল পরিকল্পনাকারী / অপ্টিমাইজারের মধ্যে একটি নির্দিষ্ট পথ পছন্দকে বাধ্য করা।
ক্রেগ রিঞ্জার

আহ, হ্যাঁ তারা কোয়েরি ইঙ্গিত সম্পর্কে সন্দেহবাদী। আমি পরিকল্পনাকারী কোডটি পড়েছি এবং দেখে মনে হয়েছিল যে জিইকিউও বিদ্যমান কোরটিতে পরিবর্তনগুলি হ্রাস করার একটি উপায়।
ব্যবহারকারী 2761431

2
অর্ডারে জোর করার জন্য কোয়েরি ইঙ্গিতগুলি বাস্তবায়নের জন্য আপনি যা অর্জন করার চেষ্টা করছেন তা কি? যদি তা হয় তবে অন্য কেউ ইতিমধ্যে এটি প্রয়োগ করেছে কিনা তা দেখুন। আপনার প্রয়োজন কেন, পরিকল্পনাকারী কেন প্রথম স্থানে ভুল পছন্দ করছেন তাও আপনার বিবেচনা করা উচিত। একটি স্ব-অন্তর্ভুক্ত পরীক্ষা কেস উত্পাদন এবং pgsql- সম্পাদনা প্রতিবেদন বিবেচনা করুন।
ক্রেগ

3
নেই pg_hint_plan : en.sourceforge.jp/projects/pghintplan , কিন্তু আমি এটা ব্যবহার করেননি। একটি ডিবিএ আমাকে বলেছিল যে এটি 9.2 এ কাজ করছে। এটি সম্পর্কে রাশিয়ান ভাষায় একটি
নিবন্ধও আছে

উত্তর:


1

GEKO এর সাথে গোলমাল না করে আপনি এটি করার একটি উপায় হ'ল সিটিই ব্যবহার করে TE

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

উদাহরণস্বরূপ, যদি আমরা ডিবিকে প্রথমে টি 2 দিয়ে টি 1-তে যোগ দিতে চাই এবং কেবল তখন টি 4 দিয়ে আমরা এর মতো কিছু চালাতে পারি:

explain 
with j1 as (select *,t1.c4 as t1c4 from t1 join t2 on (t1.c2=t2.id))
    ,j2 as (select * from j1 join t4 on (t1c4=t4.id))
select * from j2;

এর ফলস্বরূপ:

                                  QUERY PLAN                                   
-------------------------------------------------------------------------------
CTE Scan on j2  (cost=51485.00..67785.00 rows=815000 width=64)
CTE j1
 ->  Hash Join  (cost=3473.00..14521.00 rows=815000 width=40)
       Hash Cond: (t2.id = t1.c2)
       ->  Seq Scan on t2  (cost=0.00..26.30 rows=1630 width=20)
       ->  Hash  (cost=1637.00..1637.00 rows=100000 width=20)
             ->  Seq Scan on t1  (cost=0.00..1637.00 rows=100000 width=20)
CTE j2
 ->  Hash Join  (cost=289.00..36964.00 rows=815000 width=64)
       Hash Cond: (j1.t1c4 = t4.id)
       ->  CTE Scan on j1  (cost=0.00..16300.00 rows=815000 width=44)
       ->  Hash  (cost=164.00..164.00 rows=10000 width=20)
             ->  Seq Scan on t4  (cost=0.00..164.00 rows=10000 width=20)
(13 rows)

এটি কেবল একটি উদাহরণ, আপনি এটি প্রয়োজন হিসাবে এটি প্রায় কাছাকাছি পরিবর্তন করতে পারেন - কোনও অবস্থাতেই পিজি বিভিন্ন সিটিইর মধ্যে ক্রম পরিবর্তন করতে পারে না।

আশা করি এটা সাহায্য করবে :)

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