Miguel,
Thank you for the reply.
I created a third script with the syntax you suggested, and the result
was similar to the first script, about 11.5 to 12 seconds.
The interesting thing is that in all three cases, when I use the unix
"time" command to time the execution, the "user" and "sys" portion of the
execution is about the same. user = 0.20, sys = 0.02.
This indicates to me that the bottle neck is not in the execution of the
PERL, but maybe in the postmaster daemon. The system I am testing with
is a PII, 400 mhz with 256 ram. It is not doing anything else at this
time, but running these test.
Interestingly enough under Oracle, the new script takes about the same
time as the other two, 1-1.5 seconds.
Kate Collins
mig@utdt.edu wrote:
> I believe the PostgreSQL optimizer is fooled by many ORs and switches
> to sequential scans: it cannot estimate properly the quantity of
> results that will be returned.
>
> Try it in one go, as
>
> $sql = "SELECT notam_id, TO_CHAR(full_issue_date, 'DD-MON-YYYY
> HH24:MI')
> FROM notam_details
> WHERE
> item_a IN
> ('EGKB','EGDM','EGHH','EGGD','EGVN','EGFF',
> 'EGDC','EGTC','EGDR','EGTE','EGLF','EGTG',
> 'EGBJ','EGLC','EGKK','EGLL','EGSS','EGGW',
> 'EGMD','EGDL','EGUM','EGHD','EGHE','EGKA',
> 'EGHI','EGMC','EGDG','EGFH','EGDY','EGJA',
> 'EGJB','EGJJ')";
>
> The optimizer should (I think) like this better and use the indices,
> without requiring that you iterate the queries from the frontend.
>
> As I am trying to learn these things too, I will appreciate knowing
> about the result of your tests: please keep me posted.
>
> Thanks
>
> Miguel Sofer
--
=================================================
Katherine (Kate) L. Collins
Senior Software Engineer/Meteorologist
Weather Services International (WSI Corporation)
4 Federal Street
Billerica, MA 01821
EMAIL: klcollins@wsicorp.com
PHONE: (978) 670-5110
FAX: (978) 670-5100
http://www.intellicast.com
