Re: Strangely Variable Query Performance - Mailing list pgsql-performance

From Steve
Subject Re: Strangely Variable Query Performance
Date
Msg-id Pine.GSO.4.64.0704122354430.17955@kittyhawk.tanabi.org
Whole thread Raw
In response to Re: Strangely Variable Query Performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Strangely Variable Query Performance  (Tom Lane <tgl@sss.pgh.pa.us>)
choose_bitmap_and again (was Re: Strangely Variable Query Performance)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Here you go:

  detail_summary_b_record_status_idx
  detail_summary_batch_id_idx
  detail_summary_batchnum_idx
  detail_summary_carrier_id_idx
  detail_summary_duplicate_id_idx
  detail_summary_e_record_status_idx
  detail_summary_encounter_id_idx
  detail_summary_encounternum_idx
  detail_summary_export_date_idx
  detail_summary_hedis_date_idx
  detail_summary_member_name_idx
  detail_summary_member_num_idx
  detail_summary_p_record_status_idx
  detail_summary_patient_control_idx
  detail_summary_procedurecode_idx
  detail_summary_product_line_idx
  detail_summary_provider_id_idx
  detail_summary_raps_date_idx
  detail_summary_receipt_id_idx
  detail_summary_referrering_prov_id_idx
  detail_summary_rendering_prov_id_idx
  detail_summary_rendering_prov_name_idx
  detail_summary_servicedate_idx
  ds_sort_1
  ds_sort_10
  ed_cbee_norev
  ed_cbee_norev_p
  ed_cbee_rev
  ed_cbee_rev_p
  mcbe
  mcbe_p
  mcbe_rev
  mcbe_rev_p
  mcbee_norev
  mcbee_norev_p
  mcbee_rev
  mcbee_rev_p
  pcbee_norev
  pcbee_norev_p
  pcbee_rev
  pcbee_rev_p
  rcbee_norev
  rcbee_norev_p
  rp_cbee_norev
  rp_cbee_norev_p
  rp_cbee_rev
  rp_cbee_rev_p
  sd_cbee_norev
  sd_cbee_norev_p
  sd_cbee_rev
  sd_cbee_rev_p
  testrev
  testrev_p
  detail_summary_receipt_encounter_idx


On Thu, 12 Apr 2007, Tom Lane wrote:

> Steve <cheetah@tanabi.org> writes:
>> Just dropping that index had no effect, but there's a LOT of indexes that
>> refer to receipt.  So on a hunch I tried dropping all indexes that refer
>> to receipt date and that worked -- so it's the indexes that contain
>> receipt date that are teh problem.
>
> I'm still not having any luck reproducing the failure here.  Grasping at
> straws again, I wonder if it's got something to do with the order in
> which the planner examines the indexes --- which is OID order.  Could
> you send me the results of
>
> select indexrelid::regclass from pg_index where indrelid = 'detail_summary'::regclass order by indexrelid;
>
>             regards, tom lane
>

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Strangely Variable Query Performance
Next
From: Steve
Date:
Subject: Re: Question about memory allocations