pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedIs the optimizer choice right?
2+ messages / 2 participants
[nested] [flat]
* Is the optimizer choice right?
@ 2005-12-19 20:22 Carlos Benkendorf <carlosbenkendorf@yahoo.com.br>
0 siblings, 1 reply; 2+ messages in thread
From: Carlos Benkendorf @ 2005-12-19 20:22 UTC (permalink / raw)
To: pgsql-performance
Hi,
We´re running 8.03 and I´m trying to understand why the following SELECT doesn´t use iarchave05 index.
If you disable seqscan then iarchave05 index is used and the total runtime is about 50% less than when iarchave05 index is not used.
Why is the optimizer not using iarchave05 index?
select * from iparq.arript
where
(anocalc = 2005
and rtrim(inscimob) = rtrim('010100101480010000')
and codvencto2 = 1
and parcela2 >= 0)
or
(anocalc = 2005
and rtrim(inscimob) = rtrim('010100101480010000')
and codvencto2 > 1)
or
(anocalc = 2005
and rtrim(inscimob) > rtrim('010100101480010000'))
or
(anocalc > 2005)
order by
anocalc,
inscimob,
codvencto2,
parcela2;
Explain analyze with set enable_seqscan and enable_nestloop to on;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=231852.08..232139.96 rows=115153 width=896) (actual time=38313.953..38998.019 rows=167601 loops=1)
Sort Key: anocalc, inscimob, codvencto2, parcela2
-> Seq Scan on arript (cost=0.00..170201.44 rows=115153 width=896) (actual time=56.979..13364.748 rows=167601 loops=1)
Filter: (((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 = 1::numeric) AND (parcela2 >= 0::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 > 1::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) > '010100101480010000'::text)) OR (anocalc > 2005::numeric))
Total runtime: 39247.521 ms
(5 rows)
Sort (cost=232243.19..232531.55 rows=115346 width=896) (actual time=46590.246..47225.910 rows=167601 loops=1)
Sort Key: anocalc, inscimob, codvencto2, parcela2
-> Seq Scan on arript (cost=0.00..170486.86 rows=115346 width=896) (actual time=54.573..13737.535 rows=167601 loops=1)
Filter: (((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 = 1::numeric) AND (parcela2 >= 0::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 > 1::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) > '010100101480010000'::text)) OR (anocalc > 2005::numeric))
Total runtime: 47479.861 ms
(5 rows)
Sort (cost=232281.07..232569.48 rows=115365 width=896) (actual time=40856.792..41658.379 rows=167601 loops=1)
Sort Key: anocalc, inscimob, codvencto2, parcela2
-> Seq Scan on arript (cost=0.00..170515.00 rows=115365 width=896) (actual time=58.584..13529.589 rows=167601 loops=1)
Filter: (((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 = 1::numeric) AND (parcela2 >= 0::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 > 1::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) > '010100101480010000'::text)) OR (anocalc > 2005::numeric))
Total runtime: 41909.792 ms
(5 rows)
Explain analyze with set enable_seqscan and enable_nestloop to off;
; QUERY PLAN
Index Scan using iarchave05 on arript (cost=0.00..238964.80 rows=115255 width=896) (actual time=13408.139..19814.848 rows=167601 loops=1)
Filter: (((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 = 1::numeric) AND (parcela2 >= 0::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 > 1::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) > '010100101480010000'::text)) OR (anocalc > 2005::numeric))
Total runtime: 20110.892 ms
(3 rows)
Index Scan using iarchave05 on arript (cost=0.00..239091.81 rows=115320 width=896) (actual time=14238.672..21598.862 rows=167601 loops=1)
Filter: (((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 = 1::numeric) AND (parcela2 >= 0::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 > 1::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) > '010100101480010000'::text)) OR (anocalc > 2005::numeric))
Total runtime: 21967.840 ms
(3 rows)
Index Scan using iarchave05 on arript (cost=0.00..239115.06 rows=115331 width=896) (actual time=13863.863..20504.503 rows=167601 loops=1)
Filter: (((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 = 1::numeric) AND (parcela2 >= 0::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) = '010100101480010000'::text) AND (codvencto2 > 1::numeric)) OR ((anocalc = 2005::numeric) AND (rtrim((inscimob)::text) > '010100101480010000'::text)) OR (anocalc > 2005::numeric))
Total runtime: 20768.244 ms
(3 rows)
Table definition:
Table "iparq.arript"
Column | Type | Modifiers
-------------------+-----------------------+-----------
anocalc | numeric(4,0) | not null
cadastro | numeric(8,0) | not null
codvencto | numeric(2,0) | not null
parcela | numeric(2,0) | not null
inscimob | character varying(18) | not null
codvencto2 | numeric(2,0) | not null
parcela2 | numeric(2,0) | not null
codpropr | numeric(10,0) | not null
dtaven | numeric(8,0) | not null
...
...
...
Indexes:
"pk_arript" PRIMARY KEY, btree (anocalc, cadastro, codvencto, parcela)
"iarchave04" UNIQUE, btree (cadastro, anocalc, codvencto, parcela)
"iarchave02" btree (inscimob, anocalc, codvencto2, parcela2)
"iarchave03" btree (codpropr, dtaven)
"iarchave05" btree (anocalc, inscimob, codvencto2, parcela2)
Thanks in advance!
Benkendorf
---------------------------------
Yahoo! doce lar. Faça do Yahoo! sua homepage.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Is the optimizer choice right?
@ 2005-12-19 20:54 Greg Stark <gsstark@mit.edu>
parent: Carlos Benkendorf <carlosbenkendorf@yahoo.com.br>
0 siblings, 0 replies; 2+ messages in thread
From: Greg Stark @ 2005-12-19 20:54 UTC (permalink / raw)
To: Carlos Benkendorf <carlosbenkendorf@yahoo.com.br>; +Cc: pgsql-performance
Carlos Benkendorf <carlosbenkendorf@yahoo.com.br> writes:
> Hi,
>
> We´re running 8.03 and I´m trying to understand why the following SELECT doesn´t use iarchave05 index.
>
> If you disable seqscan then iarchave05 index is used and the total runtime
> is about 50% less than when iarchave05 index is not used.
>
> Why is the optimizer not using iarchave05 index?
The optimizer is calculating that the index scan would require more i/o than
the sequential scan and be slower. The only reason it isn't is because most of
the data is cached from your previous tests.
If this test accurately represents the production situation and most of this
data is in fact routinely cached then you might consider lowering the
random_page_cost to represent this. The value of 4 is reasonable for actual
i/o but if most of the data is cached then you effectively are getting
something closer to 1. Try 2 or 1.5 or so.
Note that the sequential scan has to scan the entire table. The index scan has
to scan the entire table *and* the entire index, and in a pretty random order.
If the table didn't fit entirely in RAM it would end up reading the entire
table several times over.
--
greg
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2005-12-19 20:54 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-12-19 20:22 Is the optimizer choice right? Carlos Benkendorf <carlosbenkendorf@yahoo.com.br>
2005-12-19 20:54 ` Greg Stark <gsstark@mit.edu>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox