Hello,
I am struggling to understand why for certain criteria that i supply for a
query alters the the query plan. In my "good" case i can see that an index
is used, in my bad case where i only change the text value of the criteria,
but not the criteria itslef (ie change/add the conditions) a hbitmap heap
scan of the table is performed.
Refer attached Good/Bad query plans.
The basic query is:
SELECT * FROM highrate_log_entry
WHERE
test_seq_number > 26668670
and udc = '2424'
AND (test_signal_number = 'D2030'
)
ORDER BY test_seq_number LIMIT 11
test_seq_number is the pk and is generated by a sequence.
The D2030 is the only thing that i vary between good/bad runs. The issue is
possibly related to the data spead is for the test-signal_number is not
uniform, but there does not appear to be that much difference in difference
between the first sequence number and the last sequence number (to achieve
the 11 results), when compared between the test_seq_number that yield good
or bad results.
I dont believe that the issue is to do with re-writing the query, but how
the planner chooses its path.
I am using Postgres 8.4 on windows with default postgres.conf. I have tried
changing(increasing) shared_buffers, work_mem and effective_cache_size
without success.
Any suggestions would be appreciated.
Thanks
Jason
explain analyze SELECT * FROM highrate_log_entry
WHERE
test_seq_number > 26668670
and udc = '2424'
AND (test_signal_number = 'D2030'
)
ORDER BY test_seq_number LIMIT 11
QUERY PLAN
Limit (cost=6694.14..6694.17 rows=11 width=61) (actual time=2.859..2.881
rows=11 loops=1)
-> Sort (cost=6694.14..6695.82 rows=672 width=61) (actual time=2.856..2.863
rows=11 loops=1)
Sort Key: public.highrate_log_entry.test_seq_number
Sort Method: top-N heapsort Memory: 18kB
-> Result (cost=0.00..6679.16 rows=672 width=61) (actual
time=0.973..2.484 rows=254 loops=1)
-> Append (cost=0.00..6679.16 rows=672 width=61) (actual
time=0.970..2.046 rows=254 loops=1)
-> Index Scan using high_rate_index on highrate_log_entry
(cost=0.00..8.27 rows=1 width=145) (actual time=0.009..0.009 rows=0 loops=1)
Index Cond: ((udc = 2424::numeric) AND
((test_signal_number)::text = 'D2030'::text))
Filter: (test_seq_number > 26668670::numeric)
-> Index Scan using highrate_log_entry_2424_2009_pkey on
highrate_log_entry_2424_2009 highrate_log_entry (cost=0.00..3734.01 rows=1
width=60) (actual time=0.020..0.020 rows=0 loops=1)
Index Cond: ((udc = 2424::numeric) AND
(test_seq_number > 26668670::numeric))
Filter: ((test_signal_number)::text = 'D2030'::text)
-> Index Scan using highrate_log_entry_2424_2010_udc_key
on highrate_log_entry_2424_2010 highrate_log_entry (cost=0.00..2936.88
rows=670 width=61) (actual time=0.935..1.620 rows=254 loops=1)
Index Cond: ((udc = 2424::numeric) AND
((test_signal_number)::text = 'D2030'::text))
Filter: (test_seq_number > 26668670::numeric)
Total runtime: 2.949 ms
explain analyze SELECT * FROM highrate_log_entry
WHERE
test_seq_number > 26668670
and udc = '2424'
AND (test_signal_number = 'D2048'
)
ORDER BY test_seq_number LIMIT 11
QUERY PLAN
Limit (cost=107017.91..107017.94 rows=11 width=61) (actual
time=2102.129..2102.152 rows=11 loops=1)
-> Sort (cost=107017.91..107112.96 rows=38021 width=61) (actual
time=2102.126..2102.133 rows=11 loops=1)
Sort Key: public.highrate_log_entry.test_seq_number
Sort Method: top-N heapsort Memory: 18kB
-> Result (cost=0.00..106170.15 rows=38021 width=61) (actual
time=1428.960..2066.815 rows=26497 loops=1)
-> Append (cost=0.00..106170.15 rows=38021 width=61) (actual
time=1428.957..2024.959 rows=26497 loops=1)
-> Index Scan using high_rate_index on highrate_log_entry
(cost=0.00..8.27 rows=1 width=145) (actual time=0.006..0.006 rows=0 loops=1)
Index Cond: ((udc = 2424::numeric) AND
((test_signal_number)::text = 'D2048'::text))
Filter: (test_seq_number > 26668670::numeric)
-> Index Scan using highrate_log_entry_2424_2009_pkey on
highrate_log_entry_2424_2009 highrate_log_entry (cost=0.00..3734.01 rows=22
width=60) (actual time=0.017..0.017 rows=0 loops=1)
Index Cond: ((udc = 2424::numeric) AND
(test_seq_number > 26668670::numeric))
Filter: ((test_signal_number)::text = 'D2048'::text)
-> Bitmap Heap Scan on highrate_log_entry_2424_2010
highrate_log_entry (cost=2600.42..102427.87 rows=37998 width=61) (actual
time=1428.928..1987.050 rows=26497 loops=1)
Recheck Cond: ((udc = 2424::numeric) AND
((test_signal_number)::text = 'D2048'::text))
Filter: (test_seq_number > 26668670::numeric)
-> Bitmap Index Scan on
highrate_log_entry_2424_2010_udc_key (cost=0.00..2590.92 rows=93311 width=0)
(actual time=370.824..370.824 rows=90282 loops=1)
Index Cond: ((udc = 2424::numeric) AND
((test_signal_number)::text = 'D2048'::text))
Total runtime: 2102.291 ms
--
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
