postgres_fdw কর্মক্ষমতা ধীর

বিদেশী সম্পর্কে নিম্নলিখিত কোয়েরিটি ৩.২ মিলিয়ন সারিগুলিতে নির্বাহ করতে প্রায় 5 সেকেন্ড সময় নেয়:

SELECT x."IncidentTypeCode", COUNT(x."IncidentTypeCode") 
FROM "IntterraNearRealTimeUnitReflexes300sForeign" x 
WHERE x."IncidentDateTime" >= '05/01/2016' 
GROUP BY x."IncidentTypeCode" 
ORDER BY 1;

আমি যখন সাধারণ টেবিলে একই ক্যোরিটি চালিত করি তখন তা .6 সেকেন্ডে ফিরে আসে। মৃত্যুদণ্ড কার্যকর করার পরিকল্পনাগুলি বেশ আলাদা:

সাধারণ টেবিল

Sort  (cost=226861.20..226861.21 rows=4 width=4) (actual time=646.447..646.448 rows=7 loops=1) 
  Sort Key: "IncidentTypeCode" 
  Sort Method: quicksort  Memory: 25kB 
  -> HashAggregate (cost=226861.12..226861.16 rows=4 width=4) (actual  time=646.433..646.434 rows=7 loops=1)
     Group Key: "IncidentTypeCode"
     -> Bitmap Heap Scan on "IntterraNearRealTimeUnitReflexes300s" x  (cost=10597.63..223318.41 rows=708542 width=4) (actual time=74.593..342.110 rows=709376 loops=1) 
        Recheck Cond: ("IncidentDateTime" >= '2016-05-01 00:00:00'::timestamp without time zone) 
        Rows Removed by Index Recheck: 12259 
        Heap Blocks: exact=27052 lossy=26888
        -> Bitmap Index Scan on idx_incident_date_time_300  (cost=0.00..10420.49 rows=708542 width=0) (actual time=69.722..69.722 rows=709376 loops=1) 
           Index Cond: ("IncidentDateTime" >= '2016-05-01 00:00:00'::timestamp without time zone) 

Planning time: 0.165 ms 
Execution time: 646.512 ms

বিদেশী টেবিল

Sort  (cost=241132.04..241132.05 rows=4 width=4) (actual time=4782.110..4782.112 rows=7 loops=1)   
  Sort Key: "IncidentTypeCode" 
  Sort Method: quicksort  Memory: 25kB
  -> HashAggregate  (cost=241131.96..241132.00 rows=4 width=4) (actual time=4782.097..4782.100 rows=7 loops=1)
     Group Key: "IncidentTypeCode"
     -> Foreign Scan on "IntterraNearRealTimeUnitReflexes300sForeign" x  (cost=10697.63..237589.25 rows=708542 width=4) (actual time=1.916..4476.946 rows=709376 loops=1) 

Planning time: 1.413 ms 
Execution time: 4782.660 ms

আমি মনে করি আমি এই GROUP BYধারাটির জন্য একটি উচ্চ মূল্য প্রদান করছি , যা বিদেশী সার্ভারে পাস করা হয় না যখন আমি EXPLAIN VERBOSE:

SELECT
    "IncidentTypeCode"
FROM
    PUBLIC ."IntterraNearRealTimeUnitReflexes300s"
WHERE
    (
        (
            "IncidentDateTime" >= '2016-05-01 00:00:00' :: TIMESTAMP WITHOUT TIME ZONE
        )
    )

এটি 700k সারি দেয়। এই সমস্যা এড়ানোর একটি উপায় আছে কি?

আমি গতকাল এই ডকুমেন্টেশন পৃষ্ঠাটি পড়তে অনেক সময় ব্যয় করেছি এবং ভেবেছিলাম use_remote_estimateসত্যে স্থির হয়ে আমার উত্তরটি পেয়েছি , তবে এর কোনও ফল হয়নি had

প্রয়োজনে অবজেক্ট তৈরি করতে বিদেশী সার্ভারে আমার অ্যাক্সেস রয়েছে। ধারাটিতে টাইমস্ট্যাম্প মানটি WHEREযে কোনও হতে পারে; এটি পূর্বনির্ধারিত মানগুলির তালিকা থেকে আসে না।

— জে-Dawg
সূত্র

৯..6

— জ্যাক বলেছেন টপান্সওয়ার্স.অ্যাকিজ

আপনি যখন বলেন বনাম সাধারণ বনাম বিদেশী টেবিল আপনি একই টেবিলে জুড়ে ছুটে চলেছেন (স্থানীয়ভাবে এবং দূরবর্তীভাবে) বা আসলে বিভিন্ন টেবিলগুলি (এটি যেমন তারা পড়ে থাকে তেমন পড়ে), যদি তারা আলাদা হয় তবে দূরবর্তী সার্ভারে সূচীকরণগুলি পরীক্ষা করে তা নিশ্চিত করুন যে তারা একই আপনি যেহেতু সম্পূর্ণ ভিন্ন তথ্য উত্সগুলি পড়তে দেখছেন এবং IntterraNearRealTimeUnitReflexes300sForeignবনাম IntterraNearRealTimeUnitReflexes300sএবং idx_incident_date_time_300 আমি অনুমান করি যে 300s একইরকম, তবে idx_incident_date_time_300বিদেশী সার্ভারে সূচকটি বিদ্যমান কিনা তা পরীক্ষা করা উচিত

— স্টে বোভ

আমি যা বুঝি সেগুলি থেকে, সমষ্টিগুলি (COUNT) দূরবর্তী সার্ভারে ধাক্কা দেয় না, যা দীর্ঘ অনুরোধের সময়টি ব্যাখ্যা করবে। দেখে মনে হচ্ছে এই বৈশিষ্ট্যটি পিজ

— জেরোম WAGNER

@ জেরোম ওয়াগনার - আশ্চর্যজনক

— জে-ডাউজি

আপনি যদি বিদেশী টেবিলটি বিশ্লেষণuse_remote_estimate করার বিষয়ে নিশ্চিত হন (আমি প্রত্যাবর্তনকারীদের সাথে খুব কাছাকাছি অনুমান দেখি, আপনি সম্ভবত এটি করতে পারেন)। এছাড়াও, পুশডাউন উন্নতি <9.5 সংস্করণে উপলব্ধ নয়। আমি এটিও ধরে নিয়েছি যে দূরবর্তী সার্ভারে আপনার একই টেবিল কাঠামো রয়েছে (সূচিপত্র সহ)। কম কার্ডিনালটির কারণে যদি বিটম্যাপের প্রয়োজন হয় তবে পুশডাউন প্রক্রিয়াটির সীমাবদ্ধতার কারণে এটি সূচকটি ব্যবহার করবে না। আপনি বিটিআরই সূচক স্ক্যান ( টাইমস্ট্যাম্প রেঞ্জ) জোর করতে ফেরত সারিগুলির পরিমাণ হ্রাস করতে চাইতে পারেন)। দুর্ভাগ্যক্রমে, রিমোট সার্ভারে সেকস্ক্যান এড়ানোর কোনও পরিষ্কার উপায় নেই যদি ফিল্টারটি টেবিলের সারিগুলির + 10% সরিয়ে দেয় (পরিকল্পনাকারী বিবেচনা করে যে পুরো টেবিলটি স্ক্যান করা পড়া চেয়ে সস্তা, তবে এই শতাংশের পরিমাণে পৃথক হতে পারে)। আপনি যদি এসএসডি ব্যবহার করে থাকেন তবে আপনি সম্ভবত টুইট করার জন্য দরকারী হবেন random_page_cost)।

আপনি গ্রুপের আচরণকে আলাদা করতে সিটিই ব্যবহার করতে পারেন:

WITH atable AS (
    SELECT "IncidentTypeCode"
    FROM PUBLIC ."IntterraNearRealTimeUnitReflexes300s"
    WHERE 
       ("IncidentDateTime" 
              BETWEEN '2016-05-01 00:00:00'::TIMESTAMP WITHOUT TIME ZONE 
                  AND '2016-05-02 00:00:00'::TIMESTAMP WITHOUT TIME ZONE)
)
SELECT atable."IncidentTypeCode", COUNT(atable.IncidentTypeCode) 
FROM atable
GROUP BY atable."IncidentTypeCode" 
ORDER BY atable."IncidentTypeCode";

— 3manuek
সূত্র

পারফরম্যান্স সিটিই ব্যবহার করে একই ছিল। যদিও এলোমেলো_পৃষ্ঠা_কাস্ট সেটিংস চেষ্টা করবে। ধন্যবাদ!

— J-DawG