query optimization

Started by Kevin Duffyover 17 years ago4 messagesgeneral
Jump to latest
#1Kevin Duffy
KD@wrinvestments.com

Hello:

This posting is a follow up to this posting from July 15th.

http://archives.postgresql.org/pgsql-general/2008-07/msg00569.php

Given the following select statement

select sec.*

from security sec , positions_gsco

where positions_gsco.securitykey is NULL and

upper(positions_gsco.producttype) = 'OP' and

upper(substring(productid,1,3)) = 'CFD' and

getsectypekey('CFD') = sec.securitytypekey and

positions_gsco.taskrunkey = 359 and

positions_gsco.issuecurrency = sec.securityissuecurrISO and

positions_gsco.strikeprice = sec.strikeprice and

positions_gsco.expirationdate = sec.expirationdate and

( positions_gsco.underlyingisin = sec.underlyingisin or

positions_gsco.underlyingcusip = sec.underlyingcusip or

positions_gsco.underlyingbloombergticker = sec.
underlyingbloomberg ) ;

Run as is this statement never returns .

Additional info:

select * from positions_gsco

where ((securitykey IS NULL) AND
(upper("substring"((productid)::text, 1, 3)) = 'CFD'::text) AND

(upper((producttype)::text) = 'OP'::text) AND (taskrunkey =
359))

Returns 2538 rows in 1625ms

select * from security

where (getsectypekey('CFD'::bpchar) = securitytypekey);

returns 2538 rows in 1078ms

so we are not dealing with very large datasets.

Security has an index defined as follows:

CREATE INDEX security_sectypekey ON "security" USING btree
(securitytypekey);

These is a total of 11443 rows in security.

If I change the getsectypekey('CFD') in the above statement to be
either ' (select getsectypekey('CFD') ) ' or '5'

I get 2632 rows in approx 4300ms. There may be an issue here with
number of rows returned. I'll look into that.

But the point is it returns in a reasonable number of seconds.

So here are the questions for the PSQL gurus:

Is getsectypekey('CFD') executing for every join (or possible join)
between positions_gsco and security?

Causing a scan of security for every possible join.

Does ' (select getsectypekey('CFD') ) ' cause the getsectype()
function to be executed once and thus

allowing the index on security to be used.

And of couse '5' makes things simple. The index on security is used.

Am I posting this in the right. If not please help me correct my error
and point me to the correct spot.

Thanks for taking a look at my issue.

Best Regards

Kevin Duffy

#2Scott Marlowe
scott.marlowe@gmail.com
In reply to: Kevin Duffy (#1)
Re: query optimization

What does the output of explain select sec.* ... have to say?

#3Klint Gore
kgore4@une.edu.au
In reply to: Kevin Duffy (#1)
Re: query optimization

Kevin Duffy wrote:

So here are the questions for the PSQL gurus:

Is getsectypekey(�CFD�) executing for every join (or possible join)
between positions_gsco and security?

Causing a scan of security for every possible join.

Does � (select getsectypekey('CFD') ) � cause the getsectype()
function to be executed once and thus

allowing the index on security to be used.

And of couse �5� makes things simple. The index on security is used.

Am I posting this in the right. If not please help me correct my error
and point me to the correct spot.

Is the function stable or volatile?

As Scott Marlowe suggested, you need to look at the explain results to
find out what the plan is in each case.

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789
Fax: 02 6773 3266
EMail: kgore4@une.edu.au

#4Kevin Duffy
KD@wrinvestments.com
In reply to: Klint Gore (#3)
Re: query optimization

I sent this follow up in yesterday, but it did not show up.
Must be doing something wrong. Here is the second try.

kd

select * from security sec
where getsectypekey('OP') = sec.securitytypekey returns 690 rows
in 1625ms EXPLAIN "Seq Scan on "security" sec (cost=0.00..507.54
rows=602 width=374)"
" Filter: (getsectypekey('OP'::bpchar) = securitytypekey)"

select * from security sec
where ( select getsectypekey('OP') ) = sec.securitytypekey
returns 690 rows in 172ms
EXPLAIN
"Bitmap Heap Scan on "security" sec (cost=16.93..368.36 rows=602
width=374)"
" Recheck Cond: ($0 = securitytypekey)"
" InitPlan"
" -> Result (cost=0.00..0.01 rows=1 width=0)"
" -> Bitmap Index Scan on security_sectypekey (cost=0.00..16.77
rows=602 width=0)"
" Index Cond: ($0 = securitytypekey)"

So this proves it is using the index.

But I think the issue is in the interaction between the numbers of rows
returned from positions_gsco and security.

kd

-----Original Message-----
From: Klint Gore [mailto:kgore4@une.edu.au]
Sent: Thursday, July 17, 2008 7:41 PM
To: Kevin Duffy
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] query optimization

Kevin Duffy wrote:

So here are the questions for the PSQL gurus:

Is getsectypekey('CFD') executing for every join (or possible join)
between positions_gsco and security?

Causing a scan of security for every possible join.

Does ' (select getsectypekey('CFD') ) ' cause the getsectype()
function to be executed once and thus

allowing the index on security to be used.

And of couse '5' makes things simple. The index on security is used.

Am I posting this in the right. If not please help me correct my error

and point me to the correct spot.

Is the function stable or volatile?

As Scott Marlowe suggested, you need to look at the explain results to
find out what the plan is in each case.

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789
Fax: 02 6773 3266
EMail: kgore4@une.edu.au