Каковы возможные способы оптимизации приведенного ниже кода postgreSQL? - PullRequest
0 голосов
/ 22 мая 2019

Я написал этот SQL-запрос для извлечения данных из базы данных greenplum. Основная таблица имеет выносливые 800 000 строк, которые я объединяю с другой таблицей. Приведенный ниже запрос занимает безумное количество времени, чтобы дать результат. Что может быть причиной более длительного времени запроса? Как это решить?

select    
          a.pole,
          t.country_name,
          a.service_area,  
          a.park_name,

          t.turbine_platform_name,
          a.turbine_subtype,
          a.pad as "turbine_name",
          t.system_number as "turbine_id",
          a.customer,
          a.service_contract,   

          a.component,
          c.vendor_mfg as "component_manufacturer",

          a.case_number,
          a.description as "case_description",
          a.rmd_diagnosis as "case_rmd_diagnostic_description",
          a.priority as "case_priority",
          a.status as "case_status",
          a.actual_rootcause as "case_actual_rootcause",
          a.site_trends_feedback as "case_site_feedback",
          a.added as "date_case_added",
          a.start as "date_case_started",
          a.last_flagged as "date_case_flagged_by_algorithm_latest",
          a.communicated as "date_case_communicated_to_field",
          a.field_visible_date as "date_case_field_visbile_date",
          a.fixed as "date_anamoly_fixed",
          a.expected_clse as "date_expected_closure",
          a.request_closure_date as "date_case_request_closure",
          a.validation_date as "date_case_closure",
          a.production_related,
          a.estimated_value as "estimated_cost_avoidance",
          a.cms,
          a.anomaly_category,
          a.additional_information as "case_additional_information",
          a.model,
          a.full_model,
          a.sent_to_field as "case_sent_to_field"

      from app_pul.anomaly_stage a
 left join ge_cfg.turbine_detail t on a.scada_number = t.system_number and a.added > '2017-12-31'
 left join tbwgr_v.pmt_wmf_tur_component_master_t c on a.component = c.component_name

Ответы [ 2 ]

0 голосов
/ 22 мая 2019

Ваш запрос в основном:

 select . . .
 from app_pul.anomaly_stage a left join
      ge_cfg.turbine_detail t 
      on a.scada_number = t.system_number and
         a.added > '2017-12-31' left join
         tbwgr_v.pmt_wmf_tur_component_master_t c
         on a.component = c.component_name

Во-первых, условие на a игнорируется, поскольку это первая таблица в left join и предложение on.Итак, я предполагаю, что вы действительно собираетесь его фильтровать, поэтому напишите запрос как:

 select . . .
 from app_pul.anomaly_stage a left join
      ge_cfg.turbine_detail t 
      on a.scada_number = t.system_number left join
      tbwgr_v.pmt_wmf_tur_component_master_t c
      on a.component = c.component_name
 where a.added > '2017-12-31'

Это может помочь с производительностью.Тогда в Postgres вам нужны индексы для turbine_detail(system_number) и pmt_wmf_tur_component_master_t(component_name).Сомнительно, что индекс помог бы в первой таблице, потому что вы уже выбираете большой объем данных.

Я не уверен, что индексы будут уместны в Greenplum.

0 голосов
/ 22 мая 2019
  1. Убедитесь, что в соединениях используются соответствующие первичные и внешние ключи.
  2. Попробуйте выполнить запрос, удалив одно левое соединение за другим, чтобы вы смогли увидеть проблему.
  3. Попробуйте использовать выполнение плана.
...